dbt Labs Says a Bug Made a Pipeline Stop Recording Run Results Without Triggering Any Visible Errors

dbt Labs publishes a status page for its service, and on its page for US Cell 1 AWS there is a write-up of an incident in April 2026. Between about 6:00 AM UTC on April 6 and 4:00 AM UTC on April 7, 2026, the write-up says, "model execution data stopped refreshing in the dbt Discovery API and dbt Catalog." The data affected was "information related to which models had run, their run times, and their success or failure status." Parts of the write-up follow, not the whole.

The Runs and the Record of Them

The work itself did not stop. "Runs continued to execute normally throughout the incident," the write-up says, and "only the reporting and visibility of those runs in the API and Catalog was impacted." The API "remained fully operational throughout; only the freshness of run state data was affected."

The runs went on. The record of their results did not. The issue, the write-up says, caused runs "to appear stale or missing," and at its peak the data was "up to 22 hours out of date."

Where It Started

The cause sat in a planned change. During "a planned infrastructure update to improve how dbt processes model execution data," the write-up says, "a bug was introduced that caused the new data pipeline to stop recording run results", and it did so "without triggering any visible errors." As a result, the Discovery API and dbt Catalog "were serving stale data showing model run history, statuses, and timing that had not updated since the issue began."

An API that answers requests, with data that has stopped changing, passes any check that asks only whether it answers.

Mitigation and Next Steps

Once the root cause was identified, the write-up says, the team "immediately rolled back the affected pipeline to restore data freshness." A targeted fix was then developed and deployed on April 7, 2026, and it "has been running in production since."

Its planned remediation would, in its words, "Expand end-to-end test coverage for high-impact user flows to improve reliability and catch critical regressions earlier," and "Build proactive data freshness monitoring for our internal metadata database, ensuring timely alerts that surface staleness issues before they impact downstream processes."

The write-up does not say how the stale data was found. For any system that reports on its own work, that is the question worth asking: what would show that the reporting has stopped?