The hourly refresh envelope is stated at 306 s of slot margin; a measured run leaves 121.6 s and sits inside the warning band, and the daily series structurally cannot show it #3119

HeaviestHourlyRefreshObservedCeilingSeconds documents its own invalidation condition — "what invalidates it is this number approaching RefreshPhaseStepMinutes x 60" — and that number has since been measured at 778.4 s, which is inside the warning band and leaves 121.6 s of slot margin where the envelope prose states 306.

This is not a claim that the constant is stale. Its doc deliberately CLOSES its population ("the scope has to CLOSE the population, not merely date it: 'up to 04:20Z' is a window that has ended and will still be true next year"), and that discipline is correct and worked. The 594 s figure remains true of the window it names. What has moved is the operating envelope the constant is stated against, which the same doc frames as a condition rather than a property.

The measurement

policy_refresh_continuous_aggregate query_store_stats_interval_hourly [1054], hourly self-metrics snapshots on 2026-09-06:

total_runs advancing +1 per hour establishes run identity from the counter rather than by inference.

The doc's own threshold language: "A value at or past the slot width is asserted as a failure rather than accommodated." 778.4 s is not past 900 s, so this is not that failure — but it is 86.5 % of the way there, and ClassifyRefreshSlotHeadroom bands it Warning.

The part worth fixing regardless of the number: the surface cannot see maxima

get_store_metrics' daily series takes that day's LAST snapshot, not its maximum (DISTINCT ON ... metric_time DESC). For 2026-09-06 that is the 23:13:34 reading — 705.2 s.

So the standard surface overstates the margin by 73.2 s and, more importantly, places the day below the warning line when a run was 28.4 s above it. Anyone re-deriving this envelope from the daily series — the natural thing to do — concludes nothing entered the warning band.

The surface most likely to be consulted structurally under-reports exactly the quantity the envelope depends on. A ceiling validated against it will drift below reality undetectably, which is a property of the instrument and not of anyone's care.

This compounds a censoring effect already recorded on this route: the hourly snapshot is taken at a fixed offset, so a run longer than that offset is not observed at all in the hour it occurs, and an isolated over-ceiling spike is dropped rather than delayed.

Suggested direction

1. Re-derive the envelope from a max-preserving source. bgw_job_stat_history carries per-run rows and is the route that can answer "what was the maximum", which the self-metrics series cannot. This is a read, not a code change, and should come first.
2. Update the envelope prose — the 306 s margin, and the "well inside its slot" reading — against whatever that source returns. Keep the closed-population discipline: state the window and close it.
3. Note on the surface itself. Wherever the daily series is offered for this kind of question, say that each point is a last snapshot rather than a maximum. get_store_metrics' description already carries careful warnings of this kind for other fields; this one is missing and it is the field an envelope check would reach for.

Step 1 is DONE — the maximum is confirmed on the uncensored route

bgw_job_stat_history was read directly. 2026-09-06's maximum is 778.4 s across 22 runs — so the figure is the day's true maximum, not merely the largest sampled, and the earlier caveat is discharged.

This also confirms the instrument property quantitatively: the daily series' 705.2 s understates the day by exactly 73.2 s, which is the figure predicted above from the last-snapshot mechanism alone.

The snapshot gap that covered 17:00–19:00 is filled: 473.1, 530.1, 523.1 s. Worth stating because it corrects a characterisation rather than just adding a point — 523.1 s is a FALL from 530.1 before the rise to 675.6, so the day's approach to its maximum is not the monotone climb it appeared to be from the incomplete series. Any argument resting on the length of that run needs re-deriving from the complete one.

So what remains here is step 2 (update the envelope prose against 778.4 s) and step 3 (make get_store_metrics say each daily point is a last snapshot rather than a maximum) — and step 3 is the one that stops this recurring.

Related

• RefreshSlotWarningSeconds rejects a 480s alternative on 'three of the five' readings — only one of the five listed readings reaches 480s, and that count is the sole stated reason #3107 made the 480 s rejection an ordering against this constant rather than a tally. That ordering is unaffected — 480 < 594 < 778.4 — so this does not reopen it.

A guard that stays GREEN while its claim stops discriminating

Three assertions in TimescaleSupportTests reference the ceiling. At a ceiling past 750 s, two go red and route correctly — their failure message already says to re-take the five-sixths decision rather than edit the assertion. The third, ceiling >= alternative, stays green and should not.

Its claim is the rejection argument for the 480 s alternative: "it would warn on the very run the compression grid is sized against." At a ceiling of 778.4 s that becomes true of the chosen 750 s line too — so the ordering stops separating the two lines. What expires is the argument, not the number, and nothing goes red to say so.

That is the failure mode where coverage looks intact because it passes. Whoever re-derives the envelope has to re-derive that argument as well, and only this note will tell them.

The blast radius is wider than that one test. Pre-existing assertions in both TimescaleSupportTests and RefreshCeilingProvenancePinTests key on the same ceiling-versus-watch-line relationship, and the doc's derived figures (the 306 s margin, the percentage above the ceiling) and the Verify population chain all move with it. Deliberately not stated as a count — the guards name each one, and a tally here would rot exactly like the one #3107 removed.