Skip to main content
Databricks logo

Is Databricks Down?

No — Databricks is up

Reachable from all 7 checked regions

Average response time: 115ms

Last checked · checks run every 6 hours

Official status page: https://status.databricks.com

Databricks uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
127ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 1 day measured so far. A dash means we have no measurement for that window.

30-day history

Jun 29: no data
Jun 30: no data
Jul 1: no data
Jul 2: no data
Jul 3: no data
Jul 4: no data
Jul 5: no data
Jul 6: no data
Jul 7: no data
Jul 8: no data
Jul 9: no data
Jul 10: no data
Jul 11: no data
Jul 12: no data
Jul 13: no data
Jul 14: no data
Jul 15: no data
Jul 16: no data
Jul 17: no data
Jul 18: no data
Jul 19: no data
Jul 20: no data
Jul 21: no data
Jul 22: no data
Jul 23: no data
Jul 24: no data
Jul 25: no data
Jul 26: no data
Jul 27: no data
Jul 28: 100.00% uptime, 26 checks
Jun 29 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
144ms
DNS 0ms TCP 4ms TLS 16ms TTFB 110ms
arn
105ms
DNS 0ms TCP 1ms TLS 13ms TTFB 92ms
bom
103ms
DNS 1ms TCP 3ms TLS 19ms TTFB 82ms
ord
124ms
DNS 0ms TCP 1ms TLS 11ms TTFB 110ms
sin
238ms
DNS 130ms TCP 0ms TLS 15ms TTFB 226ms
sjc
86ms
DNS 0ms TCP 0ms TLS 13ms TTFB 74ms
syd
70ms
DNS 0ms TCP 1ms TLS 10ms TTFB 65ms
yyz
65ms
DNS 0ms TCP 0ms TLS 10ms TTFB 56ms

What Databricks does

Databricks is a data and AI platform built around the lakehouse model, combining notebooks, SQL warehouses, pipelines and machine learning on top of cloud storage. Data teams schedule production jobs on it, so an incident usually shows up first as overnight pipelines that failed rather than as people unable to log in.

What an outage looks like

Clusters fail to start or hang in a pending state, so notebooks attach to nothing. Scheduled jobs fail at launch and the failure is only noticed the next morning. SQL warehouses will not resume, leaving dashboards timing out. Unity Catalog problems block table access while compute is healthy, and notebooks may open while every command queues.

What to do about it

Check status.databricks.com, which reports Compute, Databricks SQL, Notebooks, Unity Catalog and Lakeflow separately across many cloud regions, and also tracks dependencies including AWS EC2, S3 and Route 53. Confirm your workspace region first. Let failed jobs be rerun deliberately rather than by an automatic retry storm against a platform that is still recovering.

Is it down for everyone, or just you?

If this page says Databricks 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

Snowflake
Snowflake
AWS
AWS
MongoDB Atlas
MongoDB Atlas
Datadog
Datadog

Databricks outage FAQ

Is Databricks down or is my cluster just slow to start?
Cluster startup normally takes several minutes while cloud instances are provisioned, which is easy to mistake for a hang. Check status.databricks.com for your region and the Compute component. If the region is healthy, look at instance availability and quota in your cloud account, which cause more startup failures than Databricks incidents do.
Which region should I check on the Databricks status page?
The one your workspace runs in, visible in the workspace URL. Databricks lists many regions across cloud providers and incidents are usually confined to one. The status page also tracks upstream dependencies such as AWS EC2 and S3, which is useful when the underlying cause is the cloud provider rather than Databricks itself.
Will failed jobs rerun automatically after an outage?
Only if you configured retries, and aggressive retries against a recovering platform can make things worse. Jobs that failed at launch usually need a deliberate rerun once the status page is clear. Check for partial writes first: a job that failed midway may have committed some output, and rerunning it blindly can duplicate data.
Why can I open a notebook but not run anything?
The workspace interface and the compute layer are separate. Serving a notebook is lightweight, while running a command needs a cluster, so the editor loads during incidents that stop execution entirely. Check the Compute component rather than concluding from a working notebook that the platform is healthy and the problem is your code.
Does a Databricks outage put my data at risk?
Data sits in your own cloud storage rather than inside Databricks, so an incident affects the ability to process it, not its durability. The exposure is to jobs interrupted mid-write, which can leave partial output. Checking the state of tables written by any job that failed is worth doing before rerunning anything.

How we measure this

  • We request Databricks's public endpoint every 6 hours from Fly.io regions across six continents — 7 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 Databricks publishes an official status feed we read it too, and let it override us in both directions.

Get alerted when Databricks 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