Skip to content
Latchkey

Airflow "DagBag import timeout" in CI

Airflow imposes a per-file timeout (dagbag_import_timeout) when parsing DAGs. If a DAG does heavy work at import time (a network call, a large computation), parsing exceeds the limit and the DAG is dropped with a timeout error.

What this error means

DAG parsing fails with "AirflowTaskTimeout: DagBag import timeout for /opt/airflow/dags/x.py after 30.0s" or import errors that mention the import timeout.

Airflow
Broken DAG: [/opt/airflow/dags/big_etl.py]
airflow.exceptions.AirflowTaskTimeout: DagBag import timeout for
/opt/airflow/dags/big_etl.py after 30.0s

Common causes

Top-level code does heavy work at parse time

The DAG file runs a database query, an API call, or a large loop at module level, so every parse pays that cost and exceeds the timeout.

A blocking call with no network on the runner

An import-time external call hangs until timeout because the runner cannot reach the service.

How to fix it

Move heavy work out of top-level code

  1. Identify the slow call at module scope in the DAG file.
  2. Move it into a task callable or use deferred/templated values so it runs at execution, not parse.
  3. Re-parse to confirm import is fast.
dags/big_etl.py
def run(**context):
    # heavy work happens at task run time, not import time
    fetch_and_load()

PythonOperator(task_id='load', python_callable=run)

Raise the import timeout if parsing is legitimately slow

Increase dagbag_import_timeout only after confirming the work cannot move out of import.

Terminal
export AIRFLOW__CORE__DAGBAG_IMPORT_TIMEOUT=60

How to prevent it

  • Keep DAG files free of network and heavy work at import time.
  • Push external calls into task callables.
  • Tune dagbag_import_timeout only as a last resort.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →