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

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 agent fires a BigQuery job and blocks on it with a short timeout instead of polling the job state properly. Fix it by submitting the job, then polling job.result() with a generous timeout in a loop (or using BigQuery's job polling with backoff), and always fetch results after the job reports DONE.

data agent timed out waiting for bigquery job: polling pattern

Use this when

• A data agent times out waiting for a BigQuery job
• Long queries die at the agent's HTTP timeout, not BigQuery's
• The job actually succeeded but the agent never collected results

Not for this skill when

• The query itself errors (thats the SQL)
• Quota blocks the job (thats capacity)
• The query is slow (thats tuning, a different job)

Steps

1. Submit without blocking, then poll the job state:

job = client.query("SELECT ...")  # returns immediately
print(job.job_id, job.state)

Expected output: the job id and state (RUNNING). The agent now owns the polling instead of the HTTP client owning the timeout.

2. Wait with a timeout that matches the workload, and handle it:

try:
    rows = job.result(timeout=600)
except TimeoutError:
    print(f"job {job.job_id} still running; will re-check")

Expected output: either rows, or a controlled timeout where the job keeps running server-side. The job is not lost on timeout; only the wait gave up.

3. On timeout, re-attach to the same job instead of resubmitting:

job = client.get_job(job.job_id)
rows = job.result(timeout=600)

Expected output: results from the original job. Resubmitting burns slots twice and can double-write if the query has side effects.

4. For fire-and-forget pipelines, poll with backoff in the orchestrator:

import time
while job.state != "DONE":
    time.sleep(10)
    job.reload()

Expected output: the loop exits when the job finishes. Cap the loop with a max wait and alert rather than looping forever.

Variant phrasings

agent reports the query failed but BigQuery shows success

The wait timed out, not the query. The results are sitting in the job; re-attach (step 3).

timeouts only on the first run of the day

Cold slots and cold caches make the first query slow. The polling pattern absorbs this; a fixed short timeout doesnt.

Why it happens

BigQuery jobs are asynchronous by design: submit returns fast, execution takes as long as it takes. Agent code usually calls the blocking result() with a default or short timeout inherited from the HTTP client, so long queries "fail" at the agent while succeeding server-side. The polling pattern respects the async model instead of fighting it.

Edge cases

• job.result() with no timeout blocks forever; always pass one in agent code.
• Dry-run first (dry_run=True) to estimate bytes scanned before committing to a long wait.
• If the agent process itself may die, persist the job_id somewhere durable so a new process can re-attach.

Provenance

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

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

Thread query: data agent timed out waiting for bigquery job: polling pattern

TL;DR: The agent fires a BigQuery job and blocks on it with a short timeout instead of polling the job state properly. Fix it by submitting the job, then polling job.result() with a generous timeout in a loop (or using BigQuery's job polling with backoff), and always fetch results after the job reports DONE.