On Thursday, May 7, 2026, a frontend defect was deployed to dbt Studio that caused the application to display a blank page after login for affected users. The most concentrated customer impact occurred between 22:40 and 22:50 UTC, during which a number of users across multiple tenants were unable to load Studio. A fix was identified quickly, but its rollout was delayed by an unrelated infrastructure issue affecting deployment ordering. Service was fully restored by 00:46 UTC on May 8, and Studio has been operating normally since.
During the incident, affected users who navigated to dbt Studio saw a blank page after logging in. The editor, file tree, and project content did not load, and the issue could not be resolved by refreshing or signing back in. Logging into the dbt platform itself was unaffected, but Studio and the IDE were inaccessible for affected sessions. This was a full outage of the Studio experience for those users.
Scope of customer impact:
Time of impact: 22:40 to 22:50 UTC on May 7, 2026, with residual errors continuing until 00:46 UTC on May 8 when the fix completed rollout.
A number of users were affected across multiple tenants.
All multi-tenant regions were impacted to varying degrees, including US, AU, and EMEA, as well as US single-tenant cells. Single-tenant environments outside this set were not affected.
Only the frontend Studio experience was affected. No backend services, scheduled jobs, APIs, or customer data were impacted, and no data was lost.
The incident was caused by a frontend code defect, and the time to recover was extended by an unrelated infrastructure issue that delayed the fix from reaching production. The defect itself was a change merged into the shared frontend code that powers dbt Studio. The change introduced a duplicate initialization of an internal services component during Studio startup, which caused the application to throw an unhandled error and render a blank page before any of the IDE could load. The change passed code review but was missed by automated tests that should have caught it, because the relevant end to end test suite was configured as non blocking on pull requests at the time. The repository had recently been migrated and the work to make these tests blocking had not yet been completed. Once the defect was identified, engineering prepared a fix and merged it within the standard rollout process. However, the deployment was unable to complete in production environments due to an unrelated infrastructure issue: a number of underlying compute nodes across multiple clusters were in an unhealthy state, which prevented deployment dependencies from progressing. Because dbt Studio's deployment was configured to wait for these dependencies, the corrective release was held up even though the fix itself was ready. The infrastructure issue was subsequently traced to an AWS outage relating to availability zone event. To resolve the incident, the engineering team adjusted the deployment ordering so that the Studio fix could roll out without waiting for the blocked dependencies, and manually removed the unhealthy infrastructure nodes that were preventing recovery. The fix was then verified in every affected region.
We deployed the corrective code change to all affected environments and confirmed Studio was loading correctly in every region.
We removed the unhealthy infrastructure nodes that were blocking deployment and restored deployment health across the affected clusters.
We adjusted the deployment configuration for the Studio frontend so that a similar dependency issue would not block a customer-facing fix from rolling out in the future.
We have committed to a set of follow-up actions to reduce the likelihood and impact of a similar incident:
✅ Make the end to end test suite blocking on pull requests for the Studio frontend, so a defect of this kind cannot reach production even if it passes code review.
Add automated post deploy health checks for dbt Studio, so that a broken deployment is detected within minutes rather than relying on user reports.
Add frontend error rate alerting tied to Studio initialization failures, so that a sharp increase in client side errors after a deploy triggers an immediate page to the on call team.
✅ Build a one click rollback workflow for the Studio frontend, so future regressions can be reverted faster without manual coordination.
✅ Add automated verification that the expected version of the application is live in every target environment after each deployment, removing ambiguity about whether a release has fully landed.
Investigate the underlying infrastructure conditions that produced the unhealthy compute nodes, in coordination with the related platform incident that has been opened separately.
We sincerely apologize to the customers affected by this incident. We understand how disruptive a loss of access to dbt Studio is in the middle of the working day, and we take our responsibility to provide a reliable platform seriously. The remediation work above is already underway.
