Skip to main content

Is Bitbucket Down?

No — Bitbucket is up

Reachable from all 8 checked regions

Average response time: 144ms

Last checked · checks run every 6 hours

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

Bitbucket uptime

99.50%
Last 7 days
99.65%
Last 30 days
99.65%
Last 90 days
1034ms
Avg response, 30 days

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

30-day history

Jul 25: no data
Jul 26: no data
Jul 27: no data
Jul 28: no data
Jul 29: no data
Jul 30: no data
Jul 31: no data
Aug 1: no data
Aug 2: no data
Aug 3: no data
Aug 4: no data
Aug 5: 100.00% uptime, 16 checks
Aug 6: 100.00% uptime, 31 checks
Aug 7: 100.00% uptime, 32 checks
Aug 8: 100.00% uptime, 32 checks
Aug 9: 100.00% uptime, 32 checks
Aug 10: 100.00% uptime, 32 checks
Aug 11: 100.00% uptime, 32 checks
Aug 12: 96.88% uptime, 32 checks
Aug 13: 100.00% uptime, 32 checks
Aug 14: 100.00% uptime, 32 checks
Aug 15: 100.00% uptime, 32 checks
Aug 16: 100.00% uptime, 32 checks
Aug 17: 100.00% uptime, 32 checks
Aug 18: 100.00% uptime, 32 checks
Aug 19: 100.00% uptime, 32 checks
Aug 20: 100.00% uptime, 24 checks
Aug 21: 100.00% uptime, 24 checks
Aug 22: 100.00% uptime, 32 checks
Aug 23: 95.83% uptime, 24 checks
Jul 25 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
80ms
DNS 0ms TCP 9ms TLS 10ms TTFB 59ms
arn
140ms
DNS 0ms TCP 21ms TLS 22ms TTFB 90ms
bom
272ms
DNS 0ms TCP 3ms TLS 6ms TTFB 220ms
cdg
72ms
DNS 0ms TCP 9ms TLS 10ms TTFB 52ms
dfw
336ms
DNS 0ms TCP 32ms TLS 32ms TTFB 258ms
ewr
74ms
DNS 0ms TCP 8ms TLS 8ms TTFB 50ms
sjc
712ms
DNS 0ms TCP 70ms TLS 71ms TTFB 515ms
syd
55ms
DNS 0ms TCP 2ms TLS 3ms TTFB 46ms
yyz
130ms
DNS 0ms TCP 18ms TLS 18ms TTFB 77ms

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 all 18 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 — 8 of them answered the most recent check.
  • 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 the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required