Backup health for your monitoring stack
Two different questions get asked of the same engine. A security or compliance reader asks who did what, from where, and whether the record can be trusted: that is the audit feed, covered in wiring the audit feed into your SIEM and forwarding the audit log to your SIEM (push). An on-call engineer asks a narrower, more urgent question: is this backup healthy right now, and will something tell me the moment it stops being healthy. That second question is what this page, and the three pages under it, answer.
downpipes treats the two as genuinely separate surfaces read off the same engine state, not one feed wearing two labels. The audit feed is a hash-chained record of operator action: who signed in, who approved a restore, who changed a role. Monitoring is a live read of backup outcomes: whether the last run succeeded, how long it took, how large the archive was, and whether each destination is reachable. Wiring one does nothing for the other, and neither substitutes for it. A self-hoster running a real monitoring stack alongside downpipes typically wants both, for two different readers.
The two audiences, side by side
| Reader | Question | Surface | Documented in |
|---|---|---|---|
| Security or compliance | Who did what, from where, and can I prove the record is unaltered | The hash-chained audit feed, by pull or by push | Wiring the audit feed into your SIEM, forwarding the audit log to your SIEM (push) |
| SRE or operations | Is this backup healthy right now, and am I paged the moment it is not | Backup-health metrics, pushed or scraped, and the incident channels behind an alert | This page’s three children, plus notifications and alert events |
The two surfaces do not share fields by design. The audit feed’s events carry member emails, source IPs, roles and approver emails on purpose, because attributing who did what is the point of an audit trail, and that page states plainly that it is never described as free of personal data. The monitoring surfaces below carry none of that: a metric or a push body names a downpipe, a destination, a duration and a byte count, never a person.
Reusing what already delivers alerts, not a second alerting system
Nothing here replaces notifications. PagerDuty, the generic webhook, Slack, Microsoft Teams and email already exist as channels, and the rules that decide which event reaches which channel, the digesting of success-class events, and the delivery history all work exactly as that page describes. What monitoring adds is two more channel kinds built on the same architecture (Jira Service Management and Opsgenie share one client, and ServiceNow Event Management is the other), and one wire that was missing before: a recovered backup now emits a matching recovery event, so a channel capable of closing what it opened actually closes it. Incident channels covers all of that, including which of the existing channels can close an incident and which are fire-only by design.
The metrics side is additive in the same sense. The Prometheus /metrics endpoint and OTLP metrics push both read the identical run-history and replication state that already drives the backup-failure and backup-stale alerts described in alert events; they are a second way to observe the same facts, not a parallel source of truth.
The auto-parse effort, in three tiers
Standing up a monitoring stack usually means teaching it a new shape: a custom parser, a field mapping, a dashboard built from scratch. The build behind these pages was ordered to minimise exactly that, and the honest way to describe the result is three tiers of decreasing effort.
| Tier | What it costs you | Where it applies here |
|---|---|---|
| 1: zero setup | The wire format needs no mapping: any Prometheus-compatible tool already parses it natively. Grafana Cloud’s hosted scraper is the one case where that is the whole story, genuinely agentless. Every other tool still means pointing your own agent or collector at the endpoint, at effort that varies by vendor from a few config fields to a YAML mapping file (the per-vendor breakdown). | The Prometheus /metrics scrape surface. |
| 2: one setting | Paste one credential or one URL into a form (or, today, into an API call; see below). | OTLP push’s endpoint and auth header; PagerDuty’s routing key; a generic webhook URL; the Jira Service Management/Opsgenie and ServiceNow channels’ URL and credential. |
| 3: one-time mapping | Map a handful of fields once, in the receiving platform’s own console. | Pointing the generic webhook at Splunk On-Call, Grafana OnCall/IRM or incident.io, none of which share our field names natively. |
Tier 1 is the most valuable of the three, because a Prometheus-compatible scraper needs no translation at all: the metric names, types and labels on the wire are the ones any of these tools already expects from any exporter. It is also the one tier with a genuine catch worth knowing before you commit a scrape config to it, which the metrics page states plainly rather than glossing over.
Every surface below is set up from the console: the metrics credential and the OTLP push destination live under Settings, and the two new incident channels are kinds you add on the Notifications screen. Each page leads with that console path and gives the admin API call underneath it, for when you would rather script the setup.
Where this fits
Prometheus metrics
Mint a read-only metrics credential and point Prometheus, a Grafana Agent, the Datadog or New Relic agent, Dynatrace, Elastic, Splunk Observability or Grafana Cloud’s agentless scraper at the canonical backup-health metric set.
OTLP metrics push
The zero-agent alternative: the engine pushes the same metrics out on its own schedule. Which vendors’ OTLP intake actually accepts the body it sends, and which do not.
Incident channels
PagerDuty’s auto-resolve, the new Jira Service Management/Opsgenie and ServiceNow channels, generic-webhook recipes for three more platforms, and the honest limits of each.
For the channel and rule mechanics every incident channel sits on top of, read notifications. For the canonical, honest catalogue of which events the engine actually emits, read alert events. For the audit-feed side of the same engine, read wiring the audit feed into your SIEM and forwarding the audit log to your SIEM (push).
Last updated .