Airflow "pool slots" exhausted: how to debug

TL;DR

Tasks are stuck in scheduled state because every slot in their pool is taken. Find which pool is full, see which tasks are holding the slots, then decide: raise the slot count, move tasks to another pool, or clear the stuck tasks that are squatting. The pool is a throttle doing its job, exhaustion means the throttle is engaged somewhere it should not be.

Airflow pool slots exhausted: tasks stuck in "scheduled" with no available pool slots

Use this when

• tasks sit in scheduled state and never start
• the UI shows a pool at zero open slots
• a new DAG's tasks never get picked up by workers

Not for this skill when

• tasks are queued but workers are idle, check the executor instead
• tasks fail on start, that is a task problem not a pool problem
• the scheduler itself is down, fix that first

Steps

1. List the pools and their slot usage to find the exhausted one:

airflow pools list

Expected output: each pool with total slots and running, queued, and open counts. The exhausted pool shows zero open slots while tasks wait.

2. See which tasks are holding slots in that pool right now:

SELECT dag_id, task_id, state, pool
FROM task_instance
WHERE pool = 'my_pool' AND state IN ('running', 'scheduled', 'queued')
ORDER BY start_date;

Expected output: the tasks occupying the pool. Long-running or stuck tasks near the top are your squatters, holding slots without doing useful work.

3. Check how long the running tasks have held their slots:

SELECT task_id, state,
       EXTRACT(EPOCH FROM (NOW() - start_date))/3600 AS hours_running
FROM task_instance
WHERE pool = 'my_pool' AND state = 'running'
ORDER BY start_date
LIMIT 10;

Expected output: hours each running task has held its slot. Anything running far past its normal duration is stuck and a candidate for clearing.

4. Raise the slot count if the pool is genuinely undersized for current demand:

airflow pools set my_pool 16 "increased for backfill"

Expected output: the pool now has 16 slots. Tasks waiting in scheduled state start getting picked up on the next scheduler loop.

5. Or clear the stuck tasks that are squatting on slots so the scheduler reschedules them fresh:

airflow tasks clear my_dag --task-regex my_stuck_task --only-running --yes

Expected output: the stuck task instances clear and release their slots. The scheduler picks them up again, and this time they either run or fail fast instead of hanging.

Variant phrasings

airflow tasks stuck in scheduled state

Scheduled means waiting on a slot, a dependency, or priority weight. Step 1 distinguishes pool exhaustion from the other causes quickly.

how to increase airflow pool slots

Step 4, the pools set command. Raise it deliberately, since the pool exists to protect something downstream from overload.

airflow default_pool exhausted

Everything lands in defaultpool unless assigned elsewhere. Either raise defaultpool or move heavy DAGs to dedicated pools so one greedy DAG cannot starve the rest.

Why it happens

Pools cap how many tasks can run concurrently to protect shared resources like a warehouse or an external API. When demand exceeds slots, extra tasks wait in scheduled state indefinitely. Exhaustion is usually growth (more tasks than the pool was sized for) or leakage (stuck tasks holding slots forever), and steps 2 and 3 tell you which one you are dealing with.

Edge cases

• Raising slots without checking downstream capacity just moves the overload to the warehouse or API. Size pools against the real bottleneck.
• default_pool is shared by everything. One greedy DAG can starve the rest, so give heavy DAGs their own pools.
• Deferred tasks can hold pool slots while waiting on triggers in some versions. Check for deferrable operators piling up.
• Pool changes apply on the next scheduler loop, not instantly. Give it a minute before re-diagnosing.

Provenance

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

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

Thread query: Airflow "pool slots" exhausted: how to debug

TL;DR: Tasks are stuck in scheduled state because every slot in their pool is taken. Find which pool is full, see which tasks are holding the slots, then decide: raise the slot count, move tasks to another pool, or clear the stuck tasks that are squatting. The pool is a throttle doing its job, exhaustion means the throttle is engaged somewhere it should not be.