Is dbt Cloud Down?

No — dbt Cloud is up

Reachable from all 8 checked regions

Average response time: 194ms

Last checked 4 hours ago · checks run every 6 hours

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

dbt Cloud uptime

100%

Last 7 days

100%

Last 30 days

100%

Last 90 days

253ms

Avg response, 30 days

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

30-day history

75-day clean streak

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

242ms

DNS 128ms TCP 8ms TLS 27ms TTFB 206ms

lhr

89ms

DNS 32ms TCP 2ms TLS 8ms TTFB 71ms

nrt

215ms

DNS 138ms TCP 5ms TLS 11ms TTFB 202ms

ord

122ms

DNS 52ms TCP 1ms TLS 22ms TTFB 101ms

sin

311ms

DNS 263ms TCP 1ms TLS 6ms TTFB 301ms

sjc

110ms

DNS 46ms TCP 1ms TLS 10ms TTFB 93ms

syd

208ms

DNS 168ms TCP 0ms TLS 6ms TTFB 195ms

yyz

255ms

DNS 112ms TCP 11ms TLS 31ms TTFB 194ms

What dbt Cloud does

dbt Cloud is the hosted service from dbt Labs for building and running data transformations, letting analytics teams develop models in SQL, test them and schedule the jobs that rebuild tables in a warehouse. Downstream dashboards and reports read the tables those jobs produce, so a failure shows up later as stale data rather than immediately.

What an outage looks like

Scheduled jobs stop starting, or start and hang without producing logs, so warehouse tables quietly stay at yesterday's data. The dbt Cloud IDE will not load or loses its connection mid-session. API-triggered runs return errors, so orchestration tools upstream report failures. Dashboards keep serving successfully from the last good build, which is why the outage is often noticed by a stale number rather than an error.

What to do about it

Check status.getdbt.com and find your own deployment cell. dbt Cloud is reported per cell rather than as one service, with separate entries for US, EMEA, EU, APAC and JP across AWS, Azure and GCP, such as US Cell 1 AWS or EMEA Cell 1 Azure. Your account URL identifies the cell. If jobs missed their window, re-run them deliberately after recovery rather than waiting for the next schedule.

Is it down for everyone, or just you?

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

dbt Cloud outage FAQ

Which dbt Cloud cell is my account on?

Your dbt Cloud access URL identifies it, and the status page is organised entirely around that. Cells are listed individually, including US Cell 1 through Cell 4 on AWS, US cells on Azure and GCP, plus EMEA, EU, APAC and JP cells. An incident on one cell tells you nothing about another, so matching your cell first avoids both false alarm and false reassurance.

Do my dashboards break when dbt Cloud is down?

Usually not straight away. Dashboards read tables in your warehouse, and those tables still hold the results of the last successful run. The failure mode is stale data rather than a broken report, which is more dangerous because nobody sees an error. Anyone making a decision from a dashboard during an incident may be reading yesterday's numbers without knowing it.

Will missed scheduled jobs run automatically afterwards?

Do not assume they will. A job whose window passed during an incident is generally skipped rather than queued, so the next run happens at its normal time and the gap stays. After service returns, trigger the affected jobs manually, starting with the ones that feed reporting other people rely on, then confirm the tables actually rebuilt.

Is my warehouse affected too?

No. dbt Cloud orchestrates transformations but the data lives in your own warehouse, such as Snowflake, BigQuery or Databricks. A dbt Cloud outage stops new models being built; it does not take your warehouse offline or remove existing tables. If queries against the warehouse are also failing, that is a separate incident with your warehouse provider.

Can I still run dbt while the cloud service is down?

Yes, if you have a local setup. dbt models are version-controlled code in your own repository, so the command line tool can run them against the warehouse directly without dbt Cloud. That covers an urgent rebuild during an incident, though scheduling, logging and the shared development environment stay unavailable until the service returns.

How we measure this

We request dbt Cloud'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 dbt Cloud 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 dbt Cloud 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