dbt-labs/dbt-agent-skills2 files

Troubleshooting Dbt Job Errors

Diagnoses dbt Cloud/platform job failures by analyzing run logs, querying the Admin API, reviewing git history, and investigating data issues. Use when a dbt Cloud/platform job fails and you need to diagnose the root cause, especially when error messages are unclear or when intermittent failures occur. Do not use for local dbt development errors.

Specification
Skill ID
dbt-labs/dbt-agent-skills/troubleshooting-dbt-job-errors
Publisher
dbt-labs
Repository
dbt-agent-skills
Installs
0
Files
2
Synced
Sep 23, 2026
How to use it

Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.

dbt-labs/dbt-agent-skills/troubleshooting-dbt-job-errorsInstalls these files
  • SKILL.md
  • references/investigation-template.md

What this skill tells the agent

Troubleshooting dbt Job Errors

Systematically diagnose and resolve dbt Cloud job failures using available MCP tools, CLI commands, and data investigation.

When to Use

  • dbt Cloud / dbt platform job failed and you need to find the root cause
  • Intermittent job failures that are hard to reproduce
  • Error messages that don't clearly indicate the problem
  • Post-merge failures where a recent change may have caused the issue

Not for: Local dbt development errors - use the skill using-dbt-for-analytics-engineering instead

The Iron Rule

Never modify a test to make it pass without understanding why it's failing.

A failing test is evidence of a problem. Changing the test to pass hides the problem. Investigate the root cause first.

Rationalizations That Mean STOP

You're Thinking...Reality
"Just make the test pass"The test is telling you something is wrong. Investigate first.
"There's a board meeting in 2 hours"Rushing to a fix without diagnosis creates bigger problems.
"We've already spent 2 days on this"Sunk cost doesn't justify skipping proper diagnosis.
"I'll just update the accepted values"Are the new values valid business data or bugs? Verify first.
"It's probably just a flaky test""Flaky" means there's an overall issue. Find it. We don't allow flaky tests to stay.

Workflow

flowchart TD
    A[Job failure reported] --> B{MCP Admin API available?}
    B -->|yes| C[list_jobs, filter to target project/env]
    B -->|no| D[Ask user for logs and run_results.json]
    C --> E[list_jobs_runs by job_id, get_job_run_error]
    D --> F[Classify error type]
    E --> F
    F --> G{Error type?}
    G -->|Infrastructure| H[Check warehouse, connections, timeouts]
    G -->|Code/Compilation| I[Check git history for recent changes]
    G -->|Data/Test Failure| J[Use discovering-data skill to investigate]
    H --> K{Root cause found?}
    I --> K
    J --> K
    K -->|yes| L[Create branch, implement fix]
    K -->|no| M[Create findings document]
    L --> N[Add test - prefer unit test]
    N --> O[Create PR with explanation]
    M --> P[Document what was checked and next steps]

Step 1: Gather Job Run Information

If dbt MCP Server Admin API Available

Use these tools first - they provide the most comprehensive data:

Note: list_jobs and list_jobs_runs results may span multiple projects/environments depending on how the Admin API and request are configured. Each list_jobs entry carries project_id and environment_id; runs also carry project_id. When you have a target job, always pass job_id to list_jobs_runs. When selecting among jobs, filter to the project/environment you're investigating.
ToolPurpose
list_jobsList jobs; each entry carries project_id and environment_id for filtering to the target project/environment
list_jobs_runsGet recent run history for a specific job (always pass job_id)
get_job_run_errorGet detailed error message and context
# List jobs and filter to the target project/environment (project_id = 1234 in this example)
jobs = list_jobs()
target_jobs = [j for j in jobs if j["project_id"] == 1234]

# Get recent failed runs for each job
for job in target_jobs:
    list_jobs_runs(job_id=job["id"], status="error", limit=5)

# Get error details for a specific run
get_job_run_error(run_id=67890)

Without MCP Admin API

Ask the user to provide these artifacts:

  1. Job run logs from dbt Cloud UI (Debug logs preferred)
  2. `run_results.json` - contains execution status for each node

To get the run_results.json, generate the artifact URL for the user:

https://<DBT_ENDPOINT>/api/v2/accounts/<ACCOUNT_ID>/runs/<RUN_ID>/artifacts/run_results.json?step=<STEP_NUMBER>

Where:

  • <DBT_ENDPOINT> - The dbt Cloud endpoint. e.g
  • cloud.getdbt.com for the US multi-tenant platform (there are other endpoints for other regions)
  • ACCOUNT_PREFIX.us1.dbt.com for the cell-based platforms (there are different cell endpoints for different regions and cloud providers)
  • <ACCOUNT_ID> - The dbt Cloud account ID
  • <RUN_ID> - The failed job run ID
  • <STEP_NUMBER> - The step that failed (e.g., if step 4 failed, use ?step=4)

Example request:

"I don't have access to the dbt MCP server. Could you provide: 1. The debug logs from dbt Cloud (Job Run → Logs → Download) 2. The run_results.json - open this URL and copy/paste or upload the contents: https://cloud.getdbt.com/api/v2/accounts/12345/runs/67890/artifacts/run_results.json?step=4

Step 2: Classify the Error

Error TypeIndicatorsPrimary Investigation
InfrastructureConnection timeout, warehouse error, permissionsCheck warehouse status, connection settings
Code/CompilationUndefined macro, syntax error, parsing errorCheck git history for recent changes, use LSP tools
Data/Test FailureTest failed with N results, schema mismatchUse discovering-data skill to query actual data

Step 3: Investigate Root Cause

For Infrastructure Errors

  1. Check job configuration (timeout settings, execution steps, etc.)
  2. Look for concurrent jobs competing for resources
  3. Check if failures correlate with time of day or data volume

For Code/Compilation Errors

  1. Check git history for recent changes:

If you're not in the dbt project directory, use the dbt MCP server to find the repository:

   # Get project details including repository URL and project subdirectory
   get_project_details(project_id=<project_id>)

The response includes:

  • repository - The git repository URL
  • dbt_project_subdirectory - Optional subfolder where the dbt project lives (e.g., dbt/, transform/analytics/)

Then either:

  • Query the repository directly using gh CLI if it's on GitHub
  • Clone to a temporary folder: git clone <repo_url> /tmp/dbt-investigation

Important: If the project is in a subfolder, navigate to it after cloning:

   cd /tmp/dbt-investigation/<project_subdirectory>

Once in the project directory:

   git log --oneline -20
   git diff HEAD~5..HEAD -- models/ macros/
  1. Use the CLI and LSP tools from the dbt MCP server or use the dbt CLI to check for errors:

If the dbt MCP server is available, use its tools:

   # CLI tools
   mcp__dbt_parse()                              # Check for parsing errors
   mcp__dbt_list_models()                        # With selectos and `+` for finding models dependencies
   mcp__dbt_compile(models="failing_model")      # Check compilation
   
   # LSP tools
   mcp__dbt_get_column_lineage()                 # Check column lineage

Otherwise, use the dbt CLI directly:

   dbt parse          # Check for parsing errors
   dbt list --select +failing_model          # Check for models upstream of the failing model
   dbt compile --select failing_model  # Check compilation
  1. Search for the error pattern:
  • Find where the undefined macro/model should be defined
  • Check if a file was deleted or renamed

For Data/Test Failures

Use the `discovering-data` skill to investigate the actual data.

  1. Get the test SQL ``bash dbt compile --select project_name.folder1.folder2.test_unique_name --output json ` the full path for the test can be found with a dbt ls --resource-type test` command
  1. Query the failing test's underlying data: ``bash dbt show --inline "<query_from_the_test_SQL>" --output json ``
  1. Compare to recent git changes:
  • Did a transformation change introduce new values?
  • Did upstream source data change?

Step 4: Resolution

If Root Cause Is Found

  1. Create a new branch: ``bash git checkout -b fix/job-failure-<description> ``

Use this skill in a project

Open any RiverX project, search the Skills panel for dbt-labs/dbt-agent-skills/troubleshooting-dbt-job-errors, and install it in one click.

Use this skill