Turn dbt Cloud test failures into Linear issues automatically

PromptCreate

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.

What does this prompt do?

Checks your dbt Cloud runs every hour and finds the ones that ended in an error.
Reads the run results to see exactly which models and tests failed and why.
Opens a Linear issue for each failing model, with the model name, the failing test, the error message, and a link back to the dbt run.
Groups by model and keeps one open ticket per model, so a test that keeps failing does not flood Linear with duplicates.

What do I need to use this?

A dbt Cloud account with data tests running in your jobs, and a service token with read access to runs and artifacts.
A Linear workspace where new issues can be created.
The Linear team where these data-quality issues should land (and an assignee, if you want them auto-assigned).

How can I customize it?

Change how often it runs, from hourly to every few hours or once a day.
Choose which Linear team and assignee the issues go to.
Adjust the priority rules so your most critical models get flagged as urgent.

FAQs

Will this create a new ticket every time a test keeps failing?

No. It groups failures by model and keeps one open issue per model, so a recurring failure reuses or updates the same ticket instead of piling up duplicates.

How does it decide the priority?

It looks at the type and severity of the failure and sets a sensible Linear priority, flagging hard failures on core models higher than soft warnings on peripheral ones. You can tune these rules to match how your team ranks data issues.

Which test failures does it catch?

Any dbt data test or model that ends in an error on a run, along with the failure message dbt records for it.

Do I need to change my dbt jobs?

No. As long as your jobs run tests in dbt Cloud, this reads the results after each run finishes.

Can I send the issues to a specific team or person?

Yes. You choose the Linear team the issues land in, and you can auto-assign them to the data owner.

Related templates

Catch feature flags that never got switched on in production

Every weekday we compare your staging and production feature settings and flag only the differences that could be hurting customers.

Agentic Task

Weekly alert noise review board for incident.io on-call

Rank every incident.io alert route by how much noise it makes, see which alerts never became real incidents, and tune the worst offenders every week.

App

Morning triage board for your Kernel browser agent runs

See every overnight browser run that failed, watch the replay, and let an agent tell you whether the site changed or your own script broke.

App

Track every half finished LaunchDarkly rollout in one board

Open one board each morning to see every flag stuck partway through a rollout, how long it has sat there, and ramp or roll back with one click.

+1

App

Find the customers stuck contacting support again and again

A board that ranks the people who opened three or more separate support conversations this month, reads their threads, and files the real fix.

App

Turn shipped Linear work into Intercom product announcements

A board your product marketer opens on every ship day to turn finished engineering tickets into announcements customers actually read in your Messenger.