Skip to main content
Bitbucket logo

Is Bitbucket Down?

No — Bitbucket is up

Reachable from all 8 checked regions

Average response time: 666ms

Last checked · checks run every 6 hours

Official status page: https://bitbucket.status.atlassian.com

Bitbucket uptime

100%
Last 7 days
99.89%
Last 30 days
99.95%
Last 90 days
632ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 70 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

27-day clean streak
Sep 14: 100.00% uptime, 32 checks
Sep 15: 100.00% uptime, 32 checks
Sep 16: 96.88% uptime, 32 checks
Sep 17: 100.00% uptime, 32 checks
Sep 18: 100.00% uptime, 32 checks
Sep 19: 100.00% uptime, 32 checks
Sep 20: 100.00% uptime, 32 checks
Sep 21: 100.00% uptime, 32 checks
Sep 22: 100.00% uptime, 31 checks
Sep 23: 100.00% uptime, 24 checks
Sep 24: 100.00% uptime, 31 checks
Sep 25: 100.00% uptime, 32 checks
Sep 26: 100.00% uptime, 32 checks
Sep 27: 100.00% uptime, 32 checks
Sep 28: 100.00% uptime, 32 checks
Sep 29: 100.00% uptime, 32 checks
Sep 30: 100.00% uptime, 32 checks
Oct 1: 100.00% uptime, 31 checks
Oct 2: 100.00% uptime, 32 checks
Oct 3: 100.00% uptime, 32 checks
Oct 4: 100.00% uptime, 32 checks
Oct 5: 100.00% uptime, 32 checks
Oct 6: 100.00% uptime, 32 checks
Oct 7: 100.00% uptime, 32 checks
Oct 8: 100.00% uptime, 32 checks
Oct 9: 100.00% uptime, 32 checks
Oct 10: 100.00% uptime, 32 checks
Oct 11: 100.00% uptime, 32 checks
Oct 12: 100.00% uptime, 32 checks
Oct 13: 100.00% uptime, 32 checks
Sep 14 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams
222ms
DNS 141ms TCP 8ms TLS 9ms TTFB 201ms
arn
290ms
DNS 135ms TCP 23ms TLS 24ms TTFB 234ms
cdg
137ms
DNS 36ms TCP 9ms TLS 11ms TTFB 114ms
dfw
258ms
DNS 48ms TCP 33ms TLS 33ms TTFB 173ms
ewr
309ms
DNS 247ms TCP 7ms TLS 8ms TTFB 292ms
fra
60ms
DNS 9ms TCP 2ms TLS 3ms TTFB 51ms
gru
919ms
DNS 214ms TCP 124ms TLS 124ms TTFB 616ms
yyz
3133ms
DNS 61ms TCP 18ms TLS 19ms TTFB 3086ms

What Bitbucket does

Bitbucket is Atlassian's Git hosting service, holding source code for teams that usually also run Jira. Bitbucket Pipelines builds and deploys from the same repositories, so for many teams it is both where the code lives and how it reaches production. That combination is what makes an incident expensive: it can stop a release rather than just a browse.

What an outage looks like

Git push and pull hang or fail against bitbucket.org while the web interface still loads, because SSH and HTTPS access are separate components from the website. Pipelines queue without starting, or start and fail fetching the repository. Webhooks stop firing, so deployment tools and Jira issue links go quiet without any visible error. Source downloads and Git LFS fetches can fail on their own.

What to do about it

Read bitbucket.status.atlassian.com, which breaks the service into Website, API, Git via SSH, Git via HTTPS, Pipelines, Webhooks, Git LFS, Source downloads, Packages, Authentication and Email delivery. Match the component to what you are doing before assuming a full outage. Commits made locally are safe and will push once access returns. Pause deploys that depend on Pipelines rather than re-triggering them, since queued builds run when capacity returns.

Is it down for everyone, or just you?

If this page says Bitbucket is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 17 cities across three regions to find out where it breaks.

Test it yourself

Related services

GitHub
GitHub
GitLab
GitLab
Jira
Jira
Docker Hub
Docker Hub

Bitbucket outage FAQ

Can I keep working while Bitbucket is down?
Yes, for most of what you do. Git is distributed, so committing, branching, rebasing, viewing history and diffing all run against your local clone and need nothing from Bitbucket. What stops is anything crossing the network: push, pull, fetch, pull request review and Pipelines. Keep committing locally and push the batch when access returns rather than waiting idle.
Why does the website load when git push fails?
Because they are different components and Atlassian reports them separately. The status page lists Website, Git via SSH and Git via HTTPS as three entries precisely because the Git transport can fail while the browsing interface is healthy. If pushes fail over SSH, trying HTTPS sometimes works, and the reverse is also true. Check which transport your remote uses before concluding the whole service is unavailable.
Does a Bitbucket outage stop my deployments?
If you deploy through Bitbucket Pipelines, yes, and if you deploy through an external tool triggered by a webhook, usually also yes. Webhooks are their own component and can fail while the repository is reachable, which produces the confusing case where a push succeeds and nothing downstream reacts. A deploy tool that clones on trigger will also fail if Git access is affected even when the webhook arrived.
Does a Bitbucket incident mean Jira is down too?
Not necessarily. Atlassian runs a separate status page per product, and Bitbucket and Jira fail independently far more often than together. Shared services such as Atlassian account authentication can affect both at once, which is the case where a single sign-in problem locks you out of everything. Check the Authentication component on this page against Jira's own status before assuming a platform-wide event.
Are queued Pipelines builds lost during an outage?
Queued builds normally run once capacity returns rather than being discarded, so re-triggering the same build several times mostly produces duplicate runs competing for the same minutes. Builds that started and failed mid-incident do need re-running. The useful move during a Pipelines incident is to stop new triggers, let the queue drain when it recovers, then re-run only what actually failed.

How we measure this

  • We request Bitbucket's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Bitbucket publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Bitbucket goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 17 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required