Confirmed by execution during the review of #264: on a freshly started instance that has delivered nothing, webhooker_delivery_duration_seconds does not appear in /metrics at all (grep count 0).
initSeries in internal/metrics/metrics.go materialises every delivery counter and gauge at zero, but not deliveryDuration. The other eight webhooker_* delivery series are present from boot; this one is not.
Why it matters rather than being merely tidy: #209 exists so an operator can alert on delivery health. On a dashboard or in an alert rule, an absent series is indistinguishable from a broken exporter or a misspelled metric name — the operator cannot tell "nothing has been delivered yet" from "my monitoring is wrong". Materialising it at zero removes that ambiguity, which is the same reasoning that put the other eight in initSeries.
Narrow, and only observable before the first delivery, which is why it is not milestoned.
Definition of done:
deliveryDuration is materialised in initSeries for the same target-type label set the other delivery series use, so it appears from boot.
A test asserting webhooker_delivery_duration_seconds is present in a scrape from an instance that has delivered nothing.
If materialising a histogram at zero is judged wrong (a histogram with no observations is arguably not meaningful), close this with that reasoning recorded instead — but make the decision explicitly rather than leaving the inconsistency unexplained.
Confirmed by execution during the review of https://git.eeqj.de/sneak/webhooker/pulls/264: on a freshly started instance that has delivered nothing, `webhooker_delivery_duration_seconds` does not appear in `/metrics` at all (grep count 0).
`initSeries` in `internal/metrics/metrics.go` materialises every delivery counter and gauge at zero, but not `deliveryDuration`. The other eight `webhooker_*` delivery series are present from boot; this one is not.
Why it matters rather than being merely tidy: https://git.eeqj.de/sneak/webhooker/issues/209 exists so an operator can alert on delivery health. On a dashboard or in an alert rule, an absent series is indistinguishable from a broken exporter or a misspelled metric name — the operator cannot tell "nothing has been delivered yet" from "my monitoring is wrong". Materialising it at zero removes that ambiguity, which is the same reasoning that put the other eight in `initSeries`.
Narrow, and only observable before the first delivery, which is why it is not milestoned.
Definition of done:
- `deliveryDuration` is materialised in `initSeries` for the same target-type label set the other delivery series use, so it appears from boot.
- A test asserting `webhooker_delivery_duration_seconds` is present in a scrape from an instance that has delivered nothing.
- If materialising a histogram at zero is judged wrong (a histogram with no observations is arguably not meaningful), close this with that reasoning recorded instead — but make the decision explicitly rather than leaving the inconsistency unexplained.
Plan. The issue body is the brief, on top of #227's registry, now on next. initSeries also materialises deliveryDuration for the same target-type labels as the other delivery series, so webhooker_delivery_duration_seconds appears from boot with a zero count; a Prometheus histogram with no observations reports zero count and sum, which an alert rule can tell apart from an absent series. A test scrapes an instance that has delivered nothing and finds the series.
Model: opus-5-5
Plan. The issue body is the brief, on top of https://git.eeqj.de/sneak/webhooker/issues/227's registry, now on `next`. `initSeries` also materialises `deliveryDuration` for the same target-type labels as the other delivery series, so `webhooker_delivery_duration_seconds` appears from boot with a zero count; a Prometheus histogram with no observations reports zero count and sum, which an alert rule can tell apart from an absent series. A test scrapes an instance that has delivered nothing and finds the series.
Model: opus-5-5
Built in #427: initSeries now creates webhooker_delivery_duration_seconds for the same four target types as the other delivery series, so /metrics serves it with a zero count and sum from boot. The registration test lists it with the other series, and a new route test scrapes /metrics on a fresh instance that has delivered nothing and finds it for every target type.
Judgement call: materialised rather than closed, since a histogram with zero observations can be told apart from an absent series.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/webhooker/pulls/427: `initSeries` now creates `webhooker_delivery_duration_seconds` for the same four target types as the other delivery series, so `/metrics` serves it with a zero count and sum from boot. The registration test lists it with the other series, and a new route test scrapes `/metrics` on a fresh instance that has delivered nothing and finds it for every target type.
Judgement call: materialised rather than closed, since a histogram with zero observations can be told apart from an absent series.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Confirmed by execution during the review of #264: on a freshly started instance that has delivered nothing,
webhooker_delivery_duration_secondsdoes not appear in/metricsat all (grep count 0).initSeriesininternal/metrics/metrics.gomaterialises every delivery counter and gauge at zero, but notdeliveryDuration. The other eightwebhooker_*delivery series are present from boot; this one is not.Why it matters rather than being merely tidy: #209 exists so an operator can alert on delivery health. On a dashboard or in an alert rule, an absent series is indistinguishable from a broken exporter or a misspelled metric name — the operator cannot tell "nothing has been delivered yet" from "my monitoring is wrong". Materialising it at zero removes that ambiguity, which is the same reasoning that put the other eight in
initSeries.Narrow, and only observable before the first delivery, which is why it is not milestoned.
Definition of done:
deliveryDurationis materialised ininitSeriesfor the same target-type label set the other delivery series use, so it appears from boot.webhooker_delivery_duration_secondsis present in a scrape from an instance that has delivered nothing.Plan. The issue body is the brief, on top of #227's registry, now on
next.initSeriesalso materialisesdeliveryDurationfor the same target-type labels as the other delivery series, sowebhooker_delivery_duration_secondsappears from boot with a zero count; a Prometheus histogram with no observations reports zero count and sum, which an alert rule can tell apart from an absent series. A test scrapes an instance that has delivered nothing and finds the series.Model: opus-5-5
Built in #427:
initSeriesnow createswebhooker_delivery_duration_secondsfor the same four target types as the other delivery series, so/metricsserves it with a zero count and sum from boot. The registration test lists it with the other series, and a new route test scrapes/metricson a fresh instance that has delivered nothing and finds it for every target type.Judgement call: materialised rather than closed, since a histogram with zero observations can be told apart from an absent series.
Model: opus-5-5