Update to spark-utils package causing job run failures
dbt Cloud job runs fail with a compilation error that names the macro assertnotnull. The problem affects projects that use the spark-utils package on adapters other than Databricks and Spark. dbt Cloud reports that it released a fix in spark-utils version 0.3.5 and continues to monitor the incident.
State
Monitoring
Started
Ongoing for
50 min
Worst impact
Degraded
Timeline
2 updatesIdentified
32 min 63%
Monitoring
19 min 37%
Updates
Times in UTCAs posted by dbt Cloud
We have released a fix for the issue with the spark-utils package. Version 0.3.5 is now available on the dbt Hub and restores the previous working behaviour. Projects that resolve the latest version of spark-utils will pick up 0.3.5 automatically on their next run, and no action is required. If your `package-lock.yml` was updated to spark-utils 0.3.4, run `dbt deps --upgrade` to update it, or pin spark-utils to 0.3.5. We are continuing to monitor. Please contact Support at [support@getdbt.com](mailto:support@getdbt.com) if you continue to experience issues.
We have identified an issue with a new release (`0.3.4`) of the dbt package `spark-utils`. Jobs fail with the following compilation error: `In dispatch: No macro named 'assert_not_null' found within namespace: 'dbt'` This affects projects that depend on `spark-utils`, either directly or through another package (for example, Fivetran source packages), on adapters other than Databricks/Spark. Projects that use a `package-lock` file are not affected unless the lock file was updated after the new release. As a workaround, pin `spark-utils` to version `0.3.3` in your `packages.yml`, then run `dbt deps`. We are working on a fix to resolve the issue and will provide an update as soon as it is available. Please contact Support at [support@getdbt.com](mailto:support@getdbt.com) if you continue to experience issues.
dbt Cloud in the last 90 days
Full historyIncidents in 90 days
30
Days with an incident
29
Median duration
1 h 51 min
This incident
55% shorter than the median
Other dbt Cloud incidents
All incidentsdbt Cloud·Wizard agent conversations returning errors
dbt Cloud Wizard agent conversations that use Anthropic models returned an error on every new message. dbt Cloud reports that the incident is resolved. The incident lasted about 102 minutes.
dbt Cloud·Wizard agent conversations returning errors
dbt Cloud Wizard agent conversations returned errors on new messages. The issue affected conversations that used Anthropic models. dbt Cloud resolved the incident after about 62 minutes. As a workaround, switching to an OpenAI model restored functionality.
dbt Cloud·Cloud IDE sessions failed to load
The issue has been resolved, and all affected systems are now functioning normally as of 17:47 UTC. Between 11:24 UTC and 17:47 UTC an issue with a long running CLI worker node resulted in indefinite load times in the IDE. We have put measures in place to prevent a recurrence and IDE behavior has returned to normal. Please contact Support via email [support@getdbt.com](http://support@getdbt.com "support@getdbt.com") if you continue to experience delays and are unsure of the root cause.
dbt Cloud·Jobs list and Environment pages failing to load
dbt Cloud could not load the Jobs page, the Project and Environment pages, and run logs for some accounts on the US and EMEA instances. Scheduled jobs continued to run. dbt Cloud reports that the issue is resolved. The outage lasted about 3 hours and 25 minutes.
dbt Cloud·Git errors for projects connected to GitHub over SSH
Git operations failed for dbt Cloud projects that use a dbt-managed repository or connect to GitHub with a deploy key. The errors were "Permission denied (publickey)" in job runs and dbt Studio git actions. dbt Cloud reports that this incident is resolved. It lasted 1 minute and 43 seconds.
Follow dbt Cloud
Your coding agent knows when dbt Cloud is down, and tells you when a failure is theirs, not yours. You can also get dbt Cloud incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.live/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "dbt" and tell me if dbt Cloud has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.live/feed.xml?providers=dbt/feed subscribe https://outages.live/feed.xml?providers=dbtFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane