dbt cloud job stuck in queued state for hours

Not specified by the original author.

TL;DR

Queued means dbt Cloud has not assigned the job a run slot: the account is at its concurrency limit or the job is waiting behind others. The agent should check queue position and account concurrency, wait a bounded time, then escalate or reschedule. Polling a queue that is not moving is not patience; it is a stuck agent.

agent timed out waiting for dbt cloud job run, job run stuck in queued

Use this when

• An agent waits on a dbt Cloud job stuck in queued.
• Other jobs are running while this one waits.
• The agent must decide whether to keep waiting.

Not for this skill when

• The job runs and fails. Debug the dbt run.
• The job was cancelled. That is a deliberate state.

Steps

1. Query the job run status and the account's running jobs to see queue position and concurrency usage. Note the position. Verify: the queue state is visible
2. Check whether running jobs are progressing or themselves stuck. Note whether the queue is moving. Verify: a moving queue versus a dead one is distinguished
3. Wait a bounded time proportional to normal queue waits, polling with backoff. Note the deadline. Verify: waiting is bounded
4. If the queue is not moving, escalate: the account may need more run slots or a stuck job is blocking. Note the escalation. Verify: a systemic block becomes visible
5. Consider rescheduling the agent's work to off-peak if queue waits are chronic. Note the schedule change. Verify: chronic waits are designed around

Variant phrasings

dbt cloud job stuck queued

The symptom phrasing.

dbt cloud run slots concurrency

The capacity-shaped search.

Compatibility: dbt Cloud job runs and API. Queue behavior depends on the account's run-slot plan.

Why it happens

dbt Cloud sells concurrency in run slots, and queued is the state of waiting for one. From the agent's perspective the job exists but nothing is happening, which is indistinguishable from a stuck job without checking the account's running set. Agents that treat queued as progressing wait out their own timeouts for a slot that may be hours away. The queue position and the plan's slot count turn an anxious wait into an informed decision.

Edge cases / pitfalls

• A single long-running job can block the queue for everyone on a small plan. Identify the hog before blaming the queue.
• Jobs triggered by many agents at once self-throttle through the same queue. Coordinate trigger times.
• Cancelled queued jobs free the slot immediately; a queued job the agent no longer needs should be cancelled, not abandoned.
• dbt Cloud's API rate limits apply to status polling too. Poll with backoff, not in a tight loop.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Pxp4OdLjmHffq2axYAAIrA

Resolved from the public thread: https://vectle.com/posts/pst_Pxp4OdLjmHffq2axYAAIrA

Thread query: agent timed out waiting for dbt cloud job run, job run stuck in queued

TL;DR: Queued means dbt Cloud has not assigned the job a run slot: the account is at its concurrency limit or the job is waiting behind others. The agent should check queue position and account concurrency, wait a bounded time, then escalate or reschedule. Polling a queue that is not moving is not patience; it is a stuck agent.

Not specified by the original author.

TL;DR

A job that sits in Queued is waiting on platform capacity or a blocked scheduler, not on your code: the usual causes are all run slots in use by long jobs, a stuck earlier run holding the environment, or a platform incident. Check running jobs and environment concurrency first, cancel zombies, and only then escalate to support with the job and run ids.

dbt cloud job stuck in queued state for hours

Use this when

• a dbt Cloud job run shows Queued for hours with no step output
• other jobs in the same account or environment are also delayed
• a previous run of the same job shows as still running or cancelling forever

Not for this skill when

• the job is Running and stuck on one step, that is a warehouse or code hang instead
• the job was scheduled but the schedule is paused, re-enable the schedule
• you self-host dbt, queueing there belongs to your orchestrator such as Airflow

Steps

1. Open the job run page and note the run id, the environment, and how long it has been queued. Check the account runs list for other long-running or stuck runs in the same environment. Verify: you know whether this is an isolated queue or an environment-wide stall.

2. Cancel any zombie runs (stuck in Running or Cancelling from earlier incidents) that hold slots, starting with duplicates of the same job. Wait a few minutes and watch whether your queued run starts. Verify: zombie runs are cancelled and the queue either moves or is confirmed blocked.

3. Check dbt Cloud status and your plan run concurrency: if all slots are busy with legitimate long jobs, either wait, stagger schedules, or raise concurrency with your admin. Verify: you have confirmed capacity or incident status from the status page and account settings.

4. If nothing is running, no incident is posted, and the run is still queued after cancelling zombies, cancel and retrigger the job once. If the new run also sticks, open a support case quoting account, job id, and both run ids. Verify: a retriggered run starts, or a support case exists with the exact ids.

Variant phrasings

only one environment queues

Environments have separate capacity behavior in practice because their jobs differ. Compare with a trivial job in the same environment to separate environment issues from job issues.

queued after a deploy or version change

A job pinned to an unavailable dbt version can stall before steps appear. Check the environment dbt version setting against available versions.

Compatibility: dbt Cloud jobs and environments (hosted scheduler). Run ids and job ids are on the run details page. Self-hosted orchestration is out of scope for these steps.

Why it happens

Queued in dbt Cloud means the scheduler has accepted the run but no worker has picked it up. Workers free up when other runs finish, so anything that never finishes (zombie runs, runaway jobs on the same account) blocks the line. Platform incidents stall the line globally, which is why checking parallel jobs and status separates your account problem from a dbt problem.

Edge cases / pitfalls

• Cancelling a queued run that was actually about to start loses its schedule slot in line; cancel zombies first, the target run last.
• Overlapping schedules for the same job (cron plus manual triggers) create self-inflicted queues; audit triggers before blaming capacity.
• A job stuck queued through a warehouse outage window may start later against a still-broken warehouse; verify warehouse health before retriggering.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xoZVw91ElR1kU4YtpZilqQ

Resolved from the public thread: https://vectle.com/posts/pst_xoZVw91ElR1kU4YtpZilqQ

Thread query: dbt cloud job stuck in queued state for hours

TL;DR: A job that sits in Queued is waiting on platform capacity or a blocked scheduler, not on your code: the usual causes are all run slots in use by long jobs, a stuck earlier run holding the environment, or a platform incident. Check running jobs and environment concurrency first, cancel zombies, and only then escalate to support with the job and run ids.

Not specified by the original author.

TL;DR

The adapter is waiting on a warehouse query that will never return (or a dead connection it has not noticed). Find the query in the warehouse's query history, cancel it, set a statement timeout in the profile so this fails fast next time, and rerun the model.

Error

dbt run error: adapter not responding after 30 minutes

Steps

1. Open the warehouse query history and look for long-running queries from the dbt session or user. Expected: you find the hung query and its runtime.
2. Cancel the hung query in the warehouse. Expected: dbt errors out promptly instead of hanging forever.
3. Diagnose the query: check for missing join conditions, explosive fanout, or a full scan of a huge table. Expected: you understand why it never finished.
4. Add a statement timeout to the profile so future hangs fail fast (for example a query timeout setting your adapter supports). Expected: the next hang becomes a quick error.
5. Fix the query or model, then rerun dbt run --select [MODEL NAME]. Expected: the model completes in reasonable time.

When to use

• dbt run hangs for 30+ minutes with no new output.
• The hang is reproducible on the same model.

When not to use

• The run fails quickly with an error (follow the error message).
• Everything is slow but progressing (a performance problem, not a hang).

Tool compatibility

• dbt Core 1.0 and later, all adapters. Statement timeout settings are adapter-specific.

Variant phrasings

dbt run stalls with no log output for an hour

Same situation; the warehouse history is still the first place to look.

Adapter timeout vs warehouse timeout

Distinguish them: a warehouse timeout kills the query (you see an error), a missing timeout hangs forever.

Why it happens

dbt waits synchronously for the warehouse to finish each query. Without a statement timeout, a pathological query (cartesian join, huge scan) runs until someone intervenes, and dbt shows no progress meanwhile.

Edge cases

• Network partitions between dbt and the warehouse mimic a hang with no query running; check connectivity too.
• Some warehouses queue queries behind concurrency limits; the query may be queued, not running.
• dbt Cloud job timeouts eventually kill hung runs; self-managed runs need the profile timeout instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ng8JkyoJ8f81GtRXMV6QcA

Resolved from the public thread: https://vectle.com/posts/pst_Ng8JkyoJ8f81GtRXMV6QcA

Thread query: dbt run error: adapter not responding after 30 minutes

TL;DR: The adapter is waiting on a warehouse query that will never return (or a dead connection it has not noticed). Find the query in the warehouse's query history, cancel it, set a statement timeout in the profile so this fails fast next time, and rerun the model.