Skip to main content
Starting with agent v8.12.0, the Checkly Agent exposes Prometheus metrics at GET /metrics on the same port as the health probes (8080 by default, configurable with AGENT_SERVER_PORT). One endpoint covers every check type the agent runs. Each metric carries a component label: uptime for API checks and uptime monitors, synthetics for Browser, Multistep and Playwright checks. The uptime image only reports component="uptime".
Terminal
The agent container runs two processes. Each reports under its own component label.

​
Agent metrics

These metrics are always on.

​
Runtime metrics

The endpoint also serves the standard runtime metrics of both agent processes. Use them to size CPU and memory for the container. process_* metrics with the same name, such as process_cpu_seconds_total and process_resident_memory_bytes, appear once per component. Sum over component to get the container total.

​
Check-level metrics

Starting with agent v8.13.0, set AGENT_METRICS_PER_CHECK=true to expose one set of series per check. These series carry the labels check_id, name, check_type and tags. Timings are in seconds. Histograms have five buckets. The metrics follow the Prometheus V2 integration, with these differences:
  • Names use the checkly_agent_ prefix.
  • check_type values are upper-case, for example API or BROWSER.
  • There are no group, muted, activated or location labels, and key:value tags are not parsed into labels. Add a location label in your scrape config.
  • Heartbeat metrics and checkly_time_to_ssl_expiry_seconds are not reported. Use checkly_agent_ssl_monitor_days_until_expiry.
  • checkly_agent_browser_check_errors_total is a counter.
High cardinality. With AGENT_METRICS_PER_CHECK=true, every check adds its own set of series: one per metric, label combination and histogram bucket. An agent that runs hundreds of checks produces a scrape of tens of thousands of series, which costs memory on the agent and on your Prometheus server and slows down dashboards. Enable it only when you need per-check data from the agent, and keep check name and tags values stable, because every new value creates new series. The agent drops the series of a scheduled check after three missed runs, and the series of a check without a schedule after AGENT_METRICS_IDLE_TTL_SECONDS.

​
Reduce cardinality in Kubernetes

A check can run on any pod of a Private Location, so each check’s series appears once per pod. If your scrape config adds pod and instance labels, you store one series set per check and pod. For gauges, such as checkly_agent_check_status and checkly_agent_ssl_monitor_days_until_expiry, you can drop both labels. All pods report the same value for a check, so the last write wins and nothing is lost.
PodMonitor
Do not drop these labels from counters and histograms. Several pods then write into one series, the values interleave and rate() reports resets. Aggregate them instead, with a recording rule such as sum without (pod, instance) (rate(checkly_agent_check_result_total[5m])), or with an aggregation feature of your metrics backend.