Skip to main content
The Prizm Airflow Plugin hooks into Airflow’s run lifecycle. When a DAG run completes — success or failure — the plugin sends that run’s metadata to Prizm immediately, with no polling interval and no Airflow credentials stored in Prizm.
The plugin never reads or transmits Airflow connection secrets, variable values outside the ones listed in this guide, or data from your warehouses. It reports only DAG, task, and run metadata — plus, optionally, source code and failed-task logs, both of which you can disable.

Before you start

  • Admin access to your Airflow deployment — you need to add plugin files and restart the scheduler
  • Admin or Editor access to your Prizm workspace
  • Airflow 2.5 or later, with the requests package available in the scheduler’s Python environment (present in most Airflow installs by default)
  • Network access from the Airflow scheduler host to your Prizm workspace URL

Installation

1

Create the Airflow source in Prizm

In Prizm, go to Sources → Add Source → Airflow and set the Integration Type to Plugin.Give the source a Name and write it down exactly as typed — you will reuse it verbatim as prizm_connection_name in Step 5. Prizm uses this name to match incoming plugin data to the right source.
The name must match exactly, including case and spacing. The plugin sends its configured connection name with every request. If it doesn’t match the source name character for character, Prizm rejects the data.
2

Generate a Prizm API access token

Go to Settings → Organization → Access Tokens and generate a new token.
Copy the token immediately — it is shown only once. Store it as a secret: an Airflow Variable marked secret, or a secrets backend. Never commit it to source control.
3

Download the plugin file

Download prizm_airflow_plugin.py from the Prizm connector assets bucket:
If you received the file as a direct attachment, skip this step.
4

Place the file in your Airflow plugins folder

Copy the file into the plugins/ directory under your Airflow home, keeping the filename as-is:
Docker, Astronomer, Composer, or MWAA? Mount or bake the file into whatever location your platform treats as the Airflow plugins/ folder. The install mechanism is identical — only the path convention differs by platform.
5

Configure the plugin

Set the following as Airflow Variables via Admin → Variables in the Airflow UI, or via the CLI:
The plugin also reads PRIZM_URL, PRIZM_API_TOKEN, and PRIZM_CONNECTION_NAME from the process environment first, falling back to Airflow Variables. Use environment injection (Docker, Helm) if your scheduler is already configured that way.You can use an existing Airflow secrets backend—such as AWS Secrets Manager, Google Cloud Secret Manager, Azure Key Vault, or HashiCorp Vault—instead of storing values directly in Airflow Variables. Store prizm_urlprizm_api_token, and prizm_connection_nameusing the backend’s Airflow Variable naming convention; the plugin resolves them automatically. Alternatively, inject prizm_urlprizm_api_token, and prizm_connection_name as environment variables.Optional variables for filtering and log capture are listed in the Variable reference section below.
6

Restart the scheduler

The plugin loads only on scheduler startup. Restart the scheduler — and any workers running the same image — after placing the file and setting the variables.systemd:
Docker Compose:
The exact command depends on your deployment. The requirement is that the scheduler process restarts and loads the plugin from the same AIRFLOW_HOME where you placed the file.
7

Verify

Trigger or wait for any DAG run to complete. In Prizm, open Sources and select your source — the run appears within a few minutes, along with the DAG’s tasks and lineage.If nothing shows up, see Troubleshooting below.

How the plugin works

The plugin registers two listeners on scheduler startup:
  • on_dag_run_success — fires when a DAG run completes successfully
  • on_dag_run_failed — fires when a DAG run ends in a failure state
On each trigger, the plugin builds a payload for that run and POSTs it to {prizm_url}/api/v1/schedule/airflow/plugin using the configured Bearer token. Limitations to be aware of:
  • Failed pushes are dropped. If Prizm is briefly unreachable when a run completes, that run’s data is lost. Check the scheduler logs for entries from prizm_airflow_plugin to detect dropped pushes.
  • Only success and failure fire. Runs that are killed, marked as zombie, or otherwise end without triggering either listener produce no push — leaving a gap in the catalog.
  • Plugin pushes never prune. Each push contains data for the run that just finished, not a complete DAG inventory. Deactivating deleted or renamed DAGs requires a full sync from an API Pull or CLI source.

Variable reference


Troubleshooting


Next Steps

Setup

Create an Airflow source and configure API Pull or CLI mode.

What We Collect

Full breakdown of every field Prizm catalogs from DAG, task, and run metadata.