What causes SERVICE_UNAVAILABLE?

A brief Databricks control-plane outage or regional service degradation. The Databricks API is under heavy load and is temporarily rate-limiting or shedding requests. A network layer between the caller and the Databricks endpoint is unavailable. A maintenance window is in progress for the target workspace region

How do I fix SERVICE_UNAVAILABLE?

Step 1: Check the Databricks status page (status.databricks.com) for any ongoing incidents in your region.. Step 2: Retry the request with exponential back-off (start at 1s, double up to 60s, max 3–5 retries).. Step 3: If using the Databricks SDK or CLI, enable the built-in retry logic with appropriate timeout settings.. Step 4: If the error persists for more than 30 minutes, open a Databricks support case with the request ID.

Medium severityconnection

Power BI Refresh Error:
SERVICE_UNAVAILABLE

What does this error mean?

The Databricks REST API returned a 503 Service Unavailable response, indicating a transient platform outage or overload that prevented the request from completing.

Common causes

1A brief Databricks control-plane outage or regional service degradation
2The Databricks API is under heavy load and is temporarily rate-limiting or shedding requests
3A network layer between the caller and the Databricks endpoint is unavailable
4A maintenance window is in progress for the target workspace region

How to fix it

1Step 1: Check the Databricks status page (status.databricks.com) for any ongoing incidents in your region.
2Step 2: Retry the request with exponential back-off (start at 1s, double up to 60s, max 3–5 retries).
3Step 3: If using the Databricks SDK or CLI, enable the built-in retry logic with appropriate timeout settings.
4Step 4: If the error persists for more than 30 minutes, open a Databricks support case with the request ID.

Frequently asked questions

Should I build retry logic into every Databricks API call?

Yes. The Databricks Python SDK and Go SDK include built-in retry logic with configurable back-off. For direct HTTP calls, implement exponential back-off with jitter and respect the Retry-After header when present.

How do I distinguish a 503 from a genuine job failure?

A genuine job failure will have a specific error class in the run state message. A 503 occurs before a run is even created, so you will see no run record in the Jobs UI for that invocation.