# Turn failed dbt Cloud tests into tracked Linear issues > Every hour we check your dbt Cloud runs for failed data tests and open a Linear issue for each broken model, complete with the error, a link to the run, and a suggested priority. - Workflow type: agent - Services: dbt Cloud, Linear - Categories: Engineering, Operations - Published: 2026-07-17 ## What it does - 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 you'll need - 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). ## Prompt 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: ') 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. ## How to customize - 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. ## FAQ ### 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. Use this prompt in General Input: https://www.generalinput.com/prompts/turn-failed-dbt-cloud-tests-into-tracked-linear-issues