# Sensors, Reschedule Mode and Deferrable Operators

> Waiting without wasting workers: poke vs reschedule mode, deferrable operators and the triggerer, and timeouts that fail loudly.

- Source: https://akshaythakare.com/notes/apache-airflow/sensors-and-deferrable-operators
- Topic: Apache Airflow
- Level: intermediate
- Reading time: 2 min
- Tags: airflow, sensors, orchestration, performance
- Updated: 2026-10-11

## The cost of waiting

A sensor in default **poke** mode holds a worker slot for its whole wait. Fifty sensors waiting an hour can block every other task.

| Mode | Holds a worker while waiting? | Use for |
| --- | --- | --- |
| `poke` | Yes | Waits of seconds |
| `reschedule` | No; it frees the slot between checks | Waits of minutes to hours |
| Deferrable | No; an async triggerer does the waiting | Many long waits |

```python
from airflow.providers.amazon.aws.sensors.s3 import S3KeySensor

wait = S3KeySensor(
    task_id="wait_for_file",
    bucket_key="s3://lake/raw/orders/{{ ds }}/_SUCCESS",
    mode="reschedule",
    poke_interval=300,
    timeout=6 * 60 * 60,      # fail after 6 hours instead of waiting forever
)
```

## Deferrable operators

A deferrable operator hands its wait to the **triggerer** process, which can watch thousands of conditions with asyncio. The task resumes on a worker only when the condition is met. Many provider operators accept `deferrable=True`.

## Always set a timeout

Without `timeout`, a sensor waiting for a file that never arrives sits there silently. A timeout turns "data is late" into a failed task that alerts someone.

> **Tip: Prefer events to polling**
>
> When the upstream system can notify you (an S3 event, a dataset update, an API callback), react to the event instead of polling.