Skip to main content
This document lists every metric that Astro exports through the Universal Metrics Exporter. Use this reference to identify which metrics are available, the Prometheus labels you can query against, and how each Astro metric name maps to its upstream Apache Airflow name.
Airflow metrics for Dags or tasks with non-ASCII characters in their IDs are not supported and are not exported. Ensure all Dag IDs, task IDs, and TaskGroup IDs contain only ASCII characters (A–Z, a–z, 0–9, _, -, .).
Astro exports two categories of metrics:
  • Airflow application metrics describe the health, success, and performance of Dag execution. Astro collects these from Airflow and normalizes them before exporting them to your Prometheus endpoint.
  • Infrastructure metrics describe the resource usage and lifecycle health of the Kubernetes Pods that run each Airflow component.
Astro doesn’t export metrics outside of these tables. The mapping configuration drops any metric that doesn’t match a rule.

How Astro normalizes Airflow metrics

The format that Astro collects Airflow metrics depends on the Airflow version of your Deployment:
  • Airflow 3 and later: OpenTelemetry format.
  • Airflow 2: StatsD format.
A Deployment on Airflow 3 that also exports Airflow metrics to Datadog sends its metrics in StatsD format. Astro maps metrics in both formats to the same names, then applies the following transformations before they reach your Prometheus endpoint. For the source-of-truth mapping rules, see the Astro StatsD mappings file.
  • Airflow names become Prometheus names. Astro replaces dots with underscores. For example, airflow.dag_processing.import_errors becomes airflow_dag_processing_import_errors.
  • Astro adds type and unit suffixes. The metric names in this document don’t include them. Astro adds _total to every counter name, so airflow_ti_successes exports as airflow_ti_successes_total. On Astro Runtime 3.3 and later, Astro adds _milliseconds to the name of each timer that Airflow sends in OpenTelemetry format. Gauge names don’t change. See Timers.
  • Variable name parts become Prometheus labels. High-cardinality identifiers move out of the metric name and into labels so that one metric name covers many dimensions. For example, Astro exports the Airflow metric airflow.dag.<dag_id>.<task_id>.duration as airflow_task_duration with dag_id and task_id labels.
  • Legacy and current Airflow names both flow through. Astro maps metrics that Airflow renamed across versions under both their legacy and current names so that Dags running on different Astro Runtime versions both emit. For example, both zombies_killed (Airflow 2.x) and task_instances_without_heartbeats_killed (Airflow 3 and later) export when Airflow emits them.
  • Astro adds default metadata labels. Every exported metric carries the standard Astro labels documented in Export metrics, such as deploymentId, organizationId, and workspaceId.
Dag IDs, task IDs, and TaskGroup IDs flow into metric names, so they must contain only ASCII characters (A–Z, a–z, 0–9, _, -, .). Airflow’s own validation accepts Unicode characters such as accented letters (ç, ã, ö), but metric backends don’t. StatsD silently drops metrics whose names contain non-ASCII characters, and OpenTelemetry rejects them as invalid under the instrument name syntax specification. The allowed characters for StatsD metric names are defined in Airflow’s metric validation source.Audit your Dag files for non-ASCII identifiers before you enable metrics:
Rename any non-ASCII IDs to ASCII equivalents so that all metrics export correctly.

Airflow application metrics

Apache Airflow classifies metrics into three types based on how the value behaves over time: counters, gauges, and timers. The following tables use Airflow’s classification. For background on each type, see the Apache Airflow metrics reference. The Name column lists each metric’s name before Astro adds type and unit suffixes. See How Astro normalizes Airflow metrics.

Counters

A counter records the cumulative count of events that occur over time, such as task failures or scheduler heartbeats. Astro exports each counter with a _total suffix. For example, airflow_ti_failures exports as airflow_ti_failures_total. The astro_bundle_backend_* metrics that carry an le label are counters, not Prometheus histograms. Each event increments the counter for every le value at or above the measured value, and the Inf value counts every event. Astro doesn’t export _bucket, _sum, or _count series for these metrics.

Gauges

A gauge measures a point-in-time value that can rise and fall, such as the number of running tasks or open executor slots.

Timers

A timer measures the duration of an event, such as how long a task or Dag run takes to complete. How Astro exports a timer depends on the format that Airflow sends it in and on your Astro Runtime version. See How Astro normalizes Airflow metrics.
  • OpenTelemetry format on Astro Runtime 3.3 and later: Airflow records each timer as an OpenTelemetry exponential histogram in milliseconds. Astro exports it as a Prometheus native histogram and adds a _milliseconds suffix to its name. For example, airflow_task_duration exports as airflow_task_duration_milliseconds, and airflow_dagrun_duration exports as airflow_dagrun_duration_milliseconds. The endpoint that receives your metrics must accept native histograms. See Export metrics prerequisites.
  • OpenTelemetry format on Astro Runtime 3.0 to 3.2: Astro exports each timer value in milliseconds, under the name in the following table.
  • StatsD format: Astro exports each timer as a Prometheus summary in seconds. Each summary has series with a quantile label under the name in the following table, plus <name>_sum and <name>_count series.

Astro event scheduler metrics

The Astro event scheduler emits metrics under the airflow.astro_event_scheduler.* namespace. Astro strips the airflow. prefix and exports each metric as astro_event_scheduler_<rest>. Because this is a catch-all mapping, the specific metric names emitted depend on the version of Astro Runtime running in your Deployment.

Infrastructure metrics

Infrastructure metrics describe the Kubernetes Pods that run each Airflow component. Use them to track CPU, memory, storage, and lifecycle health.