## 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.

```text
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