hubhealthgapsflowgammaregime

Gaps — what history do we not have, why, can we get it back, and what is it costing us?

health answers “is the pipeline running right now”. This answers “what is missing from the past”. health’s unit of truth is the newest write, so it is deliberately blind behind the tail: a store can be perfectly fresh and still be full of holes, and health will correctly call that green. This walks the whole span of every store and reports the gaps inside the range — expected days against observed days on each store’s own calendar, taken from its live crontab line rather than guessed. Everything is ranked by consequence, not by hole size: a gap in a store nothing reads is noise, a gap holding a registered metric below a2_dist’s minObs 60 — so an app is rendering null percentiles right now — is the headline.

loading…

loading…

Right now

every figure against the population it belongs to, never a bare count

Ranked by consequence

what it costs, not how big the hole is

The two pictures

where the holes are in time, and which of them are worth fixing
Ribbon Map Rows
Consequence map — the same stores as a cross-section: is it worth fixing, and can it be fixed

This page’s own record

banked once per UTC day by gaps/record.php — and held to exactly the ramp rules this page applies to every other store

reading the banked record…

Every store

64 rows, pre-sorted by consequence on the server. Click any header to re-sort. Cell shading is that column’s own range, not a verdict.

Registered metrics

which metrics are returning NULL percentiles right now, and the calendar days until they cross minObs 60

Unwatched stores

row-bearing stores accruing on disk that health’s inventory does not list at all — they can freeze without anything noticing

Host outage days

days missing from at least half of the stores that expected one — one incident, not thirty separate bugs

What every column means

plain language, one point per tile