Repository navigation
Add REST API metrics (latency, QPS, errors) #56034
Description
Description
Currently, Airflow’s REST API does not emit any metrics. It would be valuable to have basic API metrics for observability.
Use case/motivation
- Track API performance (p95/p99 latency).
- Monitor usage patterns (QPS per endpoint).
- Alert on failures (error spikes).
Related issues
No response
Are you willing to submit a PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
KatalKavya96 commentedon Sep 24, 2025
rawwar commentedon Sep 24, 2025
I actually created this issue to request comments. At this time, I am not sure if this should be implemented.
pierrejeambrun commentedon Feb 24, 2026
This is a very interesting feature to get. Having telemetry for the public/ui API would be great. Eventually we can discuss adding this to the execution_api too.
We just need to agree on an instrumentation tool that fits well in the airflow ecosystem to get started and it should be pretty straight forward for a basic implementation.
Jed mentioned https://github.com/trallnag/prometheus-fastapi-instrumentator. There might be other options around.
We just need to make sure it's not impacting performance too much.
ssbytedev commentedon Feb 28, 2026
Hello, if this issue is not assigned, can I work on it?
pierrejeambrun commentedon Mar 5, 2026
@SruthiSathya Please, feel free to work on it and open a PR, you do not have to be assigned to work on a particular issue. :)
We recently updated our guidelines and we are not assigning issues anymore as per our policy,
henry3260 commentedon Mar 28, 2026
Hi @pierrejeambrun, would it make sense to use Airflow's existing stats/observability framework rather than adding a third-party library here?
That would keep the API server aligned with the rest of Airflow's metrics approach and avoid introducing a separate path just for API-server metrics. Since the library also notes some performance cost, it seems better to start with the built-in Airflow stats abstraction if possible.
pierrejeambrun commentedon Mar 30, 2026
@henry3260 Yes I think it's a good consideration. Feel free to give it a shot if you'd like I'd be glad to review a PR or a draft in that sense.
henry3260 commentedon Aug 28, 2026
Scope note, since the metrics that ship differ from the three listed in the description.
#64523 emits two metrics for
/api/v2and/uirequests:http_requests_total(counter)http_request_duration_milliseconds(timer)both tagged with
method,route(the FastAPI route template) andstatus_family(2xx/4xx/5xx).That still covers the three use cases here:
http_request_duration_milliseconds, broken down by routehttp_requests_total, broken down by routehttp_requests_totalfiltered onstatus_family="5xx", rather thana dedicated errors metric
The separate errors counter was dropped on purpose: it would duplicate series that
status_familyalready distinguishes, and keeping the tag set small was the main constraint on this change.jasperjonkhans commentedon Aug 29, 2026
Hey, I would like to give this issue a try! :)
pierrejeambrun commentedon Sep 8, 2026
@jasperjonkhans There is already an open PR for this close to being merged.
I would suggest to find another issue to work on :)