APACHE AIRFLOWAuthoring DAGs

Backfills, Retries & Deadline Alerts

How data engineers make pipelines run themselves — pick a topic on the left and its full breakdown loads here: the mental model, runnable DAGs, the failure modes that wake people at 3am, and the judgment that separates a scheduled script from an orchestrated system.

18 min readTopics chapter readerLevel · Medium
01 · Orientation

What You’ll Master Here

Retries decide how hard to try. Timeouts decide when to stop. Deadlines decide when to tell someone. Backfills decide what history exists. Four separate questions.

3 min · Topic 1 of 8

This chapter is about time and failure: running history deliberately, deciding what happens when a task breaks, and bounding how long any of it may take. It is the operational half of Airflow, and most of it is configuration you set once and live with for years.

It also contains a version change that invalidates a lot of existing material. SLAs were removed in Airflow 3.0 and Deadline Alerts replaced them in 3.1, so lateness alerting is configured differently now.

Core mental model

Retries decide how hard to try. Timeouts decide when to stop. Deadlines decide when to tell someone. Backfills decide what history exists. Four separate questions.

Why it matters

The settings here decide how long your pipeline is silently broken before anyone finds out. A generous retry policy with no alerting can burn most of a daily window before it gives up, and a backfill without a concurrency cap can take down the system you are reading from.

Backfill
Deliberately creating DAG runs for a historical date range, after the fact.
Catchup
Automatically creating runs for intervals between start_date and now, on activation. Covered in Chapter 5.
Clearing
Resetting existing task instances so they run again. Repairs runs that exist; does not create new ones.
DeadlineAlert
The Airflow 3.1 replacement for SLAs. Fires a callback when a run exceeds a threshold, while the run is still going.
Common mistake

Copying SLA configuration from an existing tutorial. sla and sla_miss_callback were removed in Airflow 3.0. The code will not do what the tutorial says, and you will believe you have lateness alerting when you have none.

Better habit

Set retries, timeouts and alerting together. Each one alone gives you a partial answer.

Treat every backfill as a load test of the source system, because that is what it is.

Check which Airflow version any retry or SLA guidance targets before applying it.

Four questions, four settings

How hard to try, when to give up, when to tell someone, and what history exists. Conflating them is how you end up with a pipeline that retries for six hours and alerts nobody.

Remember this

This is the chapter that decides how long a broken pipeline stays quiet. Configure it deliberately.