Scrape downpipes backup-health metrics with Prometheus

Prometheus reads downpipes’ backup-health metrics by scraping the engine’s /metrics endpoint. The endpoint answers in the standard Prometheus text-exposition format, so the series arrive as native gauges with nothing to map. You mint a read-only metrics token in the console, then add one scrape job pointed at the endpoint.

Because Prometheus dials in to the endpoint, this is a pull rather than a push. The one piece of real work is reaching the endpoint with the token, not teaching Prometheus the wire format.

What you need

• A Prometheus server you already run (or Grafana Alloy, which reads the same format), with network reach to your console hostname.
• Owner access to the downpipes console to mint a read-only metrics token.

Set it up

1. In the console, open Integrations, choose this vendor’s tile, and mint a read-only token in the metrics scrape scope there. It appears once as a single bearer credential, so copy it then; only its hash is stored. Minting is Owner-only, and it queues for a second Owner’s approval if you have the dual-control gate turned on.
2. Note the metrics URL shown next to the token. On the default single-hostname topology it is your console origin plus /metrics, for example https://console.example.com/metrics.
3. Add a scrape job to your Prometheus configuration, pointed at that target with the token as a bearer credential. The shape is the ordinary bearer-secured target, given below.
4. Reload Prometheus and confirm the downpipes target reports up. The series arrive with the standard # HELP and # TYPE preamble, so there is no field mapping step.
5. Add the standard staleness alert, time() - downpipe_backup_last_success_timestamp_seconds > <threshold>, with <threshold> set to each downpipe’s own cadence budget plus headroom. To also catch a downpipe that has never succeeded, add absent(downpipe_backup_last_success_timestamp_seconds{downpipe_id="<id>"}) for each downpipe.

The scrape job is the configuration every Prometheus-compatible tool already takes for a bearer-secured target:

scrape_configs:
  - job_name: downpipes
    metrics_path: /metrics
    scheme: https
    static_configs:
      - targets: ["console.example.com"]
    authorization:
      type: Bearer
      credentials: "<your metrics token>"

Good to know

• The metric names are native Prometheus fields, so nothing needs mapping, but you still add the scrape target yourself. That is an ordinary “add a job” step, not a zero-effort connect. The token is time-boxed too, defaulting to a year from the mint and capped at 400 days. Once it lapses, the scrape returns 401 until you re-mint, which replaces the old token. Put the expiry date the console shows somewhere you will see it.
• If Cloudflare Access fronts your console hostname, an unattended scrape is redirected to your team’s login page at the edge before the engine ever sees the bearer. Give the scrape job an Access service token to send as extra headers (a path-scoped Access application with a Service Auth policy), or add a narrow Bypass over /metrics, or send the metrics out with the OTLP push instead. Either way the minted credential still gates the scrape. The full credential model, the whole metric set and the Access remedy are on the Prometheus /metrics endpoint.

Last updated 24 September 2026.