Today the Checkly Prometheus endpoint exposes check status (checkly_check_status) but not the underlying HTTP response code returned by API checks and URL monitors. That code is captured and stored per result, it just isn't surfaced on the scrape endpoint.
The ask
Add an HTTP status code metric (e.g. checkly_check_http_status_code) to the Prometheus endpoint for API checks and URL monitors, labeled the same way as the existing check series (check name, group, tags, location, etc.).
Why it matters
Teams standardizing on Prometheus + Grafana for observability commonly build dashboards and alerting rules around the HTTP response code, not just up/down. The Prometheus Blackbox Exporter convention (probe_http_status_code) is the reference point most existing dashboards, recording rules, and alerts are written against.
Without the status code on the endpoint:
Dashboards that visualize response code distributions (2xx / 3xx / 4xx / 5xx breakdowns, per-endpoint status heatmaps) can't be reproduced against Checkly data.
Recording rules and alerts that key off specific codes (e.g. alert on sustained 5xx, or on unexpected redirects) have to be rewritten to use pass/fail signals, which loses fidelity.
Users migrating from Blackbox Exporter (or running Checkly alongside it) have to either drop those views or maintain two parallel stacks to keep them.
