Summary
A congestion event can appear at one view width and morph or disappear at a wider one (e.g. present at 48 h, gone/changed at 72 h+). The same incident shouldn't depend on how wide you're looking.
Root cause (working-as-designed, but a UX wart)
Congestion detection compares each hop to a baseline computed over the view window, and the fetch resolution also scales with the window (finer for short windows, coarser for long). Recurring daily congestion means a wider window sweeps more elevated periods into the baseline, so a recent event is relatively less of an outlier and may fall below threshold — while a different hop can cross instead. The boundary-refine (fine re-detection over a ±2 h neighborhood on long windows) uses yet another baseline scope, compounding it.
It's defensible ("elevated relative to typical conditions over this period"), but the same event appearing/morphing/vanishing across views is confusing.
Proposed fix (deliberate, not a quick patch)
Decouple detection from the view window: compute events once against a fixed/canonical baseline (e.g. a stable trailing window) at a fixed resolution, and let the view only change what's displayed. Events become stable across view widths.
Trade-off: detecting at fine resolution over wide ranges is exactly the fetch-volume/perf cost the current window-scaled aggregate avoids, so this needs a design pass weighing consistency vs. query cost (e.g. fixed-length baseline, cached canonical detection, or a separate detection query).
Notes
- Confirmed via the relative-baseline reasoning; not a regression — present by design in the current detector.
- Lower priority than the per-event accuracy work already landed; filing so it isn't lost.
Summary
A congestion event can appear at one view width and morph or disappear at a wider one (e.g. present at 48 h, gone/changed at 72 h+). The same incident shouldn't depend on how wide you're looking.
Root cause (working-as-designed, but a UX wart)
Congestion detection compares each hop to a baseline computed over the view window, and the fetch resolution also scales with the window (finer for short windows, coarser for long). Recurring daily congestion means a wider window sweeps more elevated periods into the baseline, so a recent event is relatively less of an outlier and may fall below threshold — while a different hop can cross instead. The boundary-refine (fine re-detection over a ±2 h neighborhood on long windows) uses yet another baseline scope, compounding it.
It's defensible ("elevated relative to typical conditions over this period"), but the same event appearing/morphing/vanishing across views is confusing.
Proposed fix (deliberate, not a quick patch)
Decouple detection from the view window: compute events once against a fixed/canonical baseline (e.g. a stable trailing window) at a fixed resolution, and let the view only change what's displayed. Events become stable across view widths.
Trade-off: detecting at fine resolution over wide ranges is exactly the fetch-volume/perf cost the current window-scaled aggregate avoids, so this needs a design pass weighing consistency vs. query cost (e.g. fixed-length baseline, cached canonical detection, or a separate detection query).
Notes