What happens to workloads and data when the primary service becomes unavailable?
Summary
- What happens depends on the scope of the failure: a single availability zone going down inside a region is handled by high availability (HA); the loss of an entire cloud region is handled by disaster recovery (DR).
- For a zone failure, the Databricks control plane fails over automatically to healthy zones, typically within a 15-minute RTO and with an RPO of 0; serverless compute fails over across zones with no configuration, and classic compute restarts affected work in another zone.
- Data stays durable: cloud object storage is regional with redundancy across zones, and workspace metadata is stored in databases replicated across zones.
- For a full regional outage, you fail over to a secondary region through a deliberate, customer-controlled process; Databricks Managed Disaster Recovery can automate cross-region replication and reconnection behind a stable URL.
- During the first ~15 minutes of a zonal outage some operations (logins, new cluster launches) may be interrupted, after which service returns to normal; some jobs may need to be restarted.
What happens to workloads and data when the primary service becomes unavailable?
The answer depends on how much of the infrastructure is affected. The Databricks Platform treats two situations differently: a failure confined to a single availability zone inside a cloud region, which high availability (HA) handles automatically, and the loss of an entire region, which disaster recovery (DR) handles through a controlled failover to a secondary region. In both cases the design goal is to keep committed data safe and get workloads running again within your recovery targets.
Why the Databricks Platform keeps workloads and data available
- Automatic failover for a zone failure. If a single availability zone is affected in a multi-zone region, the control plane fails over automatically to healthy zones, typically within a 15-minute RTO and with an RPO of 0, so no committed data is lost. See Design a high availability strategy.
- Compute keeps running or restarts. Serverless compute provides automatic multi-zone failover with no additional configuration. For classic compute, workloads restart in a different availability zone if the original zone fails; if a driver node is lost, the cluster manager restarts the job and cluster in another zone. Cluster nodes are distributed across zones when workspace subnets span multiple zones.
- Data stays durable. Cloud object storage is regional by default with data redundancy across zones, DBFS root data is not affected by a zone failure, and workspace metadata is stored in databases replicated across zones. See Intra-region high availability guarantees.
- What you may notice during a zonal outage. Within the first roughly 15 minutes, users may be unable to log in, new clusters may not launch, running clusters may restart or terminate, and some APIs may be unavailable. After that window, operations typically return to normal; classic compute may need a manual restart if the driver was lost, and some jobs may need to be re-run.
- Recovery from a full regional outage. When an entire region is lost, you fail over to a secondary region. The typical workflow is to detect and confirm the failure, stop workspace activity, run the secondary-region recovery procedure to redirect routing and connections, repoint downstream systems such as BI tools and schedulers, then declare the secondary region operational and re-trigger jobs; you fail back to the primary region once it recovers. Because replication to the secondary region is periodic, define how much data loss is acceptable for each workload. See the disaster recovery guide.
- Managed Disaster Recovery. Databricks Managed Disaster Recovery continuously replicates Unity Catalog metadata, managed table data, and workspace assets to a secondary region and provides a stable URL that survives failover so clients reconnect without manual DNS changes. In a planned failover with both regions online, workspaces are expected to be failover-ready in under a minute; in an unplanned failover it can take up to about 6 hours after the primary region comes back before both workspaces are failover-ready again. See How Databricks Managed Disaster Recovery helps Capital One achieve lakehouse resilience.
- HA and DR work together. High availability protects against a zone failure automatically with no data loss, while disaster recovery protects against a regional outage through a controlled, cross-region failover. Most production workloads use both for end-to-end resilience.
Getting started
- Set an RTO and RPO for each workload, then read Design a high availability strategy to plan for zone failures.
- Choose serverless compute for automatic multi-zone resilience, or spread classic compute subnets across at least two availability zones.
- Plan cross-region recovery with the disaster recovery guide, and consider Databricks Managed Disaster Recovery for an automated option.
- Test your recovery procedures regularly so real recovery matches your targets.
FAQs
What happens if one availability zone goes down?
In a multi-zone region, the control plane fails over automatically to healthy zones, typically within a 15-minute RTO and with an RPO of 0. Serverless compute fails over across zones automatically, and classic compute restarts affected work in another zone.
Is my data lost when a service becomes unavailable?
For a zone failure, no committed data is lost (RPO of 0), and cloud storage is regional with redundancy across zones. For a full regional outage, replication to the secondary region is periodic, so define an acceptable data-loss window per workload.
How do I recover from a full region outage?
Fail over to a secondary region using the documented recovery workflow, or use Databricks Managed Disaster Recovery, which continuously replicates metadata, managed table data, and workspace assets and provides a stable URL that survives failover.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.