Edge Health time-window toggle (24h / 7d / 30d) — parked 2026-05-17

DARE.CO.UK · PARKED SKETCH · 2026-05-18

Mirrored from ~/.claude/.../memory/project_edge_health_time_toggle_parked.md. This is a design sketch parked for future build — read for context, not as a current deliverable.

Dan’s end-of-day ask 2026-05-17. Add a pill-style time-window toggle (24h / 7d / 30d) above the Edge Health 4-card row. Verified 2026-05-17 evening — both adapters (httpRequests1hGroups for 24h, httpRequests1dGroups for 7d/30d) already wired in dare_cf_analytics.py; build is ~45 min UI binding + per-card reframe per window. 90d stays as the static cards’ baseline, not a toggle option.

Dan, 2026-05-17 end-of-day: “add a toggle to ‘edge health’, similar pattern [screenshot of 24h / 7d / 30d pill]. Plumbing is complete already, should be easy enough to model. It should give great feedback.”

Visual reference (Dan’s screenshot):

Same pattern as the existing Trend/Live cache-chart toggle and the Weekday/Month bar-chart toggle. Pill background, dark-filled active state, light hover.

Why “plumbing is already complete”:

The current Edge Health adapter (_edge_health_cards() in dare_cf_analytics.py) queries CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF GraphQL via httpRequests1hGroups (or similar). The same query accepts arbitrary time-range parameters — 24h is the current default; 7d and 30d are 1-line since/until adjustments. The card-rendering function takes the resulting numbers; no re-architecting needed.

Sketch:

�STASH6�

Each card already has a delta (vs prior period); the toggle reshapes WHICH prior period the delta references and which window the headline number summarises.

Cycle pre-fill (sketch · strategise · audit · plumbing · UI):

• Sketch. Above. Toggle pill, sibling to existing Trend/Live and Weekday/Month toggles. Aligned to the right of the section header per visual reference.
• Strategise. Three decisions ~~for next session to resolve~~ resolved 2026-05-17 evening — see “Implementation specifics” further down: 1. ~~Default window~~ → 30d (month’s read, matches mental model; 24h one click away for incident mode). 2. ~~State persistence~~ → localStorage (user who picks a window probably wants it next visit too). 3. ~~Delta semantics per window~~ → vs-prior-same-window (24h vs prior 24h, 7d vs prior 7d, 30d vs prior 30d — simpler narrative, matches the baseline-label phrasing).
• Audit. Confirm CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF GraphQL httpRequests1dGroups (daily bucket) is available for 7d/30d ranges. Confirm rate-limit cost (3× the queries per refresh vs current). Confirm the _edge_health_cards() function takes a window: str arg cleanly.
• Plumbing. Likely a single def fetch_edge_metrics(window: str) helper that switches between 1h/1d bucket queries based on window. Cache results in ~/Downloads/dare_analytics_cache/ keyed by window so multi-window panels don’t multiply refresh time.
• UI. ~40 LOC — pill toggle markup (reuse .cache-toggle / .trend-tabs CSS), JS click handler (~15 LOC, swap data-view attribute, re-render the cards block from the prefetched data), localStorage persistence if chosen.

Expected build time: ~45 min total via the full cycle. The “plumbing complete” observation makes this a small UI bind, not a multi-day rebuild.

Verified plumbing + per-card reframe — 2026-05-17 evening

After Dan flagged the screenshot of the current Edge Health row, I checked the adapters in ~/bin/dare_cf_analytics.py. Both required granularities are already wired:

No new query shape, no new auth, no new code path. The toggle is wiring + UI, not infrastructure.

Per-card reframe (the 4 Edge Health cards)

Current state (per Dan’s 2026-05-17 screenshot): two cards already say “(90d)” in their title because their meaning collapses without a window; two cards are point-in-time (“today” / “right now”). The toggle reframes each card per window:

Baseline label shifts per window

Top-right copy (currently vs 90-day baseline · click any alert to view in Cloudflare) needs to switch per window: - 24h selected → vs prior 24h · click any alert to view in Cloudflare - 7d selected → vs prior 7d · click any alert to view in Cloudflare - 30d selected → vs prior 30d · click any alert to view in Cloudflare

The “click any alert to view in Cloudflare” tail stays constant; only the baseline-period phrase moves.

Why not include 90d in the toggle?

The current cards already render a 90d view as the static default (that’s what’s in Dan’s screenshot — “bandwidth offloaded (90d)”, “5xx error share (90d)”, and the implicit “+45pp vs 90 days ago” delta on cache-hit-rate). 90d is the long-baseline context the cards live inside. The value of the toggle is the shorter windows — “what’s happening now / this week / this month” reads that the 90d view can’t surface. Adding 90d as a toggle option would just duplicate the static default.

If a user ever needs to drop the 90d frame entirely and only see (say) 7d in isolation, the current toggle pattern already supports it — they pick 7d and the baseline phrase + per-card numbers re-render coherently. The 90d static framing is “the page’s resting state,” not “one of four toggle options.”

Implementation specifics (resolved from the parked decisions above)

• Default window: 30d — matches the “month’s read” mental model and aligns delta semantics with what most decisions need (“is this month different from last month?”). 24h is one click away when incident-response mode is wanted.
• State persistence: localStorage. The user who picks 7d once probably wants 7d next visit too. ~3 LOC.
• Delta semantics: vs-prior-same-window. 24h shows vs prior 24h; 7d shows vs prior 7d; 30d shows vs prior 30d. Simpler narrative (“is this period different from the period before”) and matches the baseline-label phrasing above.
• Pre-fetch all 3 windows at render time — ~3 GraphQL calls per dashboard refresh, well within CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF tier. Caching keyed by (card, window) in ~/Downloads/dare_analytics_cache/. JS swap is then a pure DOM op, no re-fetch on click.
• Sparklines re-scale per window — 24h shows hourly points; 7d shows daily points; 30d shows daily points. SVG paths regenerate from the prefetched data on toggle click.

Why this gives “great feedback” (Dan’s words):

The current dashboard answers “what’s happening RIGHT NOW” (24h). The toggle adds “what’s been happening THIS WEEK” and “what’s the MONTHLY normal” — different mental models, different decisions enabled:

• 24h: incident response — “is something broken now?”
• 7d: weekly hygiene — “are we trending in the right direction?”
• 30d: monthly cadence — “what’s the steady-state baseline for this metric?”

Three reads from one toggle. Each card more useful at each horizon. Dan can decide which one’s the daily-glance default later; today’s data only supports the 24h read.

Cross-section applicability (Dan, also 2026-05-17 — “All the headings can have this carry-over”):

The toggle isn’t only for Edge Health. Dan named the canonical set of sections that should all inherit the 24h/7d/30d pattern, each with their own toggle:

Same pill markup, same JS click-handler, same ?window=... query parameter into the CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF GraphQL adapter. Per-section state (each toggle independent) OR global state (one toggle controls all sections) — strategise decision in build session.

Plumbing decision matters: cache adapters keyed by (section, window) so the page can render multiple sections at different windows without re-fetching. CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF GraphQL rate-limit allows this at ~3× the current query count, well within tier.

Portfolio applicability:

Same pattern lifts to dogwood / audrey / gf.cx dashboards when those exist. The window parameter generalises to any time-series gauge — wherever a dashboard renders a “right now” reading, the toggle adds “and what’s been happening” for free.

Sibling memories:

• feedback_sketch_audit_plumbing_ui_cycle.md — the cycle this build follows.
• feedback_expose_underlying_data_value.md — the plumbing → multiple-UI-surfaces principle (24h/7d/30d are three surfaces on one plumbing source).
• user_refinements_compound.md — small UI add compounding on prior plumbing work.
• feedback_edge_health_cards — the existing 4-card section this toggles above.

Resume conditions:

• Next dashboard session — fresh eyes, ~45 min budget.
• Or whenever a multi-horizon Edge Health read would have answered a “is this normal” question that the 24h-only view couldn’t.