airflow.exceptions.AirflowException: connection id not found

TL;DR

Airflow looks up connections by id in the metadata database or your secrets backend; not found means the id is misspelled, it exists in a different environment, or the backend the task reads is not the one you wrote it to. Check the exact conn id spelling first, then confirm it exists in the environment the task actually runs in. Environment-variable connections need the AIRFLOWCONN prefix and JSON or URI format.

airflow.exceptions.AirflowException: connection id not found

Use this when

• A task fails with AirflowException naming a connection id.
• The connection exists in the UI but the task cannot find it.
• It works locally but fails in staging or prod.

Not for this skill when

• The connection exists but authentication fails. That is a credentials problem.
• You need a new connection type. Check provider package versions instead.

Steps

1. Copy the conn id from the error and compare it character by character with the stored connection. Note any typo, case, or underscore difference. Verify: spelling is ruled out
2. List connections in the exact environment the task runs in, not just your laptop. Note whether the id exists there. Verify: environment mismatch is confirmed or ruled out
3. If you use a secrets backend, verify the task's backend configuration points at the same backend you wrote to. Note the read path matches the write path. Verify: backend mismatch is ruled out
4. For environment-variable connections, check the AIRFLOWCONN[CONN_ID] variable name, prefix, and URI or JSON format. Note airflow connections get lists it. Verify: the variable form is valid
5. Re-run the single failing task after the fix and confirm it resolves the connection. Note the task proceeds past connection lookup. Verify: the lookup succeeds

Variant phrasings

airflow connection not found

The shortened phrasing.

airflow conn id does not exist

The paraphrase search.

Compatibility: Airflow 2.x with any secrets backend. AIRFLOWCONN variable format is stable; some backends require provider packages for the conn type.

Why it happens

Connections are just rows keyed by conn id, and Airflow resolves them at task runtime in the worker's environment, not at DAG parse time on the scheduler. Every mismatch between those two environments, a connection created in the UI of one deployment, a secrets backend mounted only on the scheduler, a typo that only shows at runtime, surfaces as this error. It is almost always an environment or spelling problem, not an Airflow bug.

Edge cases / pitfalls

• Conn ids are case-sensitive. MyConn and myconn are different connections.
• The test button in the UI runs on the webserver, which may have different env vars than workers. A green test does not prove workers can resolve it.
• Extra fields in JSON-formatted AIRFLOWCONN variables must be valid JSON. One stray quote breaks the whole variable.
• Deleting and recreating a connection with the same id can leave stale cached entries on long-lived workers. Restart workers after connection changes.

Provenance

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