Turn failed dbt Cloud tests into tracked Linear issues

Run this every hour. The goal is to catch dbt Cloud data-quality test failures and turn them into tracked Linear issues, opening one issue per failing model so a recurring failure never spawns duplicate tickets.

First, use dbt Cloud's List Runs to find runs on my account that finished with an error since the last time this workflow ran. In dbt Cloud a run status of 20 means Error, so filter to status 20 and order by the finish time so the most recent failures come first. Only process runs that completed after the previous check (roughly the last hour). Remember the newest finished run you have already handled so you do not reprocess the same runs on the next pass.

For each errored run, use Retrieve Run Artifact to download run_results.json. Read the results array and pull out every node whose status is 'fail' or 'error'. These are the failing data tests and models. For each one, capture the model (or node) name, the specific test that failed, and the failure message that dbt recorded. Also keep the run id and the run's link in dbt Cloud so you can reference it later.

Group the failures by the model they belong to. For each distinct failing model, first check Linear for an existing open issue for that model using Search Issues or List Issues. Give every issue a stable title that includes the model name (for example 'dbt data-quality failure: <model_name>') so a prior ticket is easy to find. If an open issue already exists for that model, do not create a duplicate. Leave it as is, or add a short comment noting the latest failure and run. Only create a new issue when there is no open issue for that model yet.

When a new ticket is needed, use Linear's Create Issue in my data team. Put the stable model key in the title and write a clear Markdown description that includes the model name, the failing test or tests, the exact error message or messages, and a link back to the run in dbt Cloud so someone can jump straight to the logs. If several tests failed on the same model, list them all in the one issue rather than splitting them up.

Set a sensible Linear priority based on severity. Linear priorities are 1 = Urgent, 2 = High, 3 = Normal, 4 = Low. Treat failures on core or heavily depended-on models, and hard failures such as uniqueness or not-null violations, as higher priority. Treat softer signals such as freshness warnings or tests on peripheral models as lower priority. Use your judgement and note the reason briefly in the issue.

The key rule: open one issue per failing model, not one per run. If the same test keeps failing hour after hour, it should map to a single tracked issue, not a growing pile of tickets.