Defining SLAs on Tasks
The sla parameter on a task is a timedelta measured from the DAG run's scheduled start (not from when the task actually begins) after which, if the task instance has not yet succeeded, the scheduler logs an SLA miss and records it in the SlaMiss table; this is fundamentally different from a timeout, which kills a running task, because an SLA miss is purely observational and does not stop or fail the task instance.
Cricket analogy: Like a broadcaster's target over-rate rule that flags a fielding side for being behind schedule without actually stopping play, an SLA miss is logged when a task instance hasn't finished by its deadline but the task keeps running rather than being killed.
sla_miss_callback and Alerting Integrations
You register an sla_miss_callback function at the DAG level, which the scheduler invokes with the list of SlaMiss records whenever a deadline is breached, letting you push a message to Slack, PagerDuty, or an email list; independently, on_failure_callback and the DAG-level default_args email_on_failure/email_on_retry settings handle outright failures rather than lateness, so a robust pipeline typically wires up both SLA-miss alerting for slowness and failure alerting for breakage, since one can occur without the other.
Cricket analogy: Like a stadium's PA system separately announcing a rain delay update versus a match abandonment, sla_miss_callback alerts on lateness while on_failure_callback alerts on an outright failed task instance, since a task can be slow without failing or fail without being slow.
Setting Realistic SLA Thresholds
Because sla is measured against the DAG's scheduled start rather than the DAG run's actual trigger time, a DAG that's queued behind other DAGs waiting for executor slots can trip its SLA even though every individual task ran efficiently, so SLA thresholds should be set generously enough to absorb normal queuing variance and should typically be applied to a handful of business-critical tasks rather than every task in the DAG, to avoid alert fatigue that causes real breaches to be ignored.
Cricket analogy: Like setting a target over-rate that accounts for normal drinks breaks and DRS reviews rather than an unrealistically tight pace, an sla threshold should be generous enough to absorb normal executor queuing delays rather than tripping on every ordinary DagRun.
import pendulum
from airflow import DAG
from airflow.operators.python import PythonOperator
def notify_slack_on_sla_miss(dag, task_list, blocking_task_list, slas, blocking_tis):
message = f"SLA missed for DAG {dag.dag_id}: {[s.task_id for s in slas]}"
# send_to_slack(message)
print(message)
with DAG(
dag_id="daily_revenue_report",
start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
schedule="0 6 * * *",
catchup=False,
sla_miss_callback=notify_slack_on_sla_miss,
) as dag:
build_report = PythonOperator(
task_id="build_report",
python_callable=lambda: None,
sla=pendulum.duration(hours=2),
)SLA misses are visible in the Airflow UI under Browse > SLA Misses, independent of whether the underlying task ultimately succeeded, which makes it easy to audit chronic lateness even for tasks that always eventually complete.
Applying sla to every task in a large DAG generates noisy, low-value alerts during normal executor contention; reserve sla for the handful of tasks whose lateness actually has business impact, such as a report that must land before a 9am stakeholder meeting.
- sla is a timedelta measured from the DAG run's scheduled start, not from actual task start time or wall-clock now.
- An SLA miss is purely observational: it's logged in the SlaMiss table but does not stop or fail the task instance.
- sla_miss_callback lets you push custom alerts (Slack, PagerDuty, email) whenever a deadline is breached.
- on_failure_callback and email_on_failure/email_on_retry handle outright task failures, a distinct concern from lateness.
- SLA thresholds should absorb normal executor queuing variance to avoid false-positive alerts.
- Reserve sla for business-critical tasks to prevent alert fatigue that causes real breaches to be ignored.
- SLA Misses are browsable in the Airflow UI, useful for auditing chronic lateness independent of task success.
Practice what you learned
1. From what point in time is a task's sla timedelta measured?
2. What happens to a task instance when it misses its SLA?
3. Which callback should you use to alert specifically on outright task failure rather than lateness?
4. Why can a DAG trip its SLA even if every task ran efficiently?
5. Why is applying sla to every task in a large DAG discouraged?
Was this page helpful?
You May Also Like
Retries and Error Handling
Configuring per-task retries, retry delays, callbacks, and trigger rules so Airflow DAGs recover gracefully from transient failures.
The Scheduler
How Airflow's scheduler parses DAGs, evaluates dependencies, and triggers task instances to keep pipelines running on time.
Backfilling and Catchup
Understanding Airflow's catchup behavior and the airflow dags backfill command for (re)processing historical data intervals.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics
ProgrammingPowerShell Study Notes
Programming · 30 topics