Is the service being called, is it slowing down, are errors rising, and has the model's output distribution moved? Four numbers and four charts, derived from a request log the service writes about itself.
/analytics/summary and /analytics/timeseries; the rendering rules (formats, thresholds, null handling) are the page's own, re-implemented here. Run it live in two commands.client ──POST /predict──→ middleware: start clock → route scores, writes probability
and model_version to request.state
→ middleware: stop clock, append one entry (in `finally`)
↓
deque(maxlen=200_000) ← the only data source
↓
GET /analytics/summary GET /analytics/timeseries
this window · previous · Δ one row per bucket, gaps kept
Nothing is not zero. An empty window has no average response time; the API returns null and the page renders -. Empty buckets keep their place with requests: 0 so an outage stays visible instead of being joined across. Failed requests never reached the model, so they don't drag the probability average down.
Honest about the source. in_memory_api_logs means every entry came from a request the service served. in_memory_api_logs+synthetic_backfill means at least one entry was injected by the demonstration backfill tool — and the page says so in a banner. Both captures here contain backfilled history, because a seven-day chart needs seven days.
Alerts are window averages, as specified — which has a blind spot: a single bad day inside a healthy week averages out under both thresholds while being obvious in the charts. Move the sliders above and watch which alerts fire on the degraded week.