dashboard: add a daily usage + uptime report cron

[JadenFiotto-Kaufman]

What

The dashboard has a monitor cron, but it is an alerting job — it fires on transitions (down / back up / models failed) and says nothing while things are fine. There was no way to answer "what happened on NDIF today?" without opening Grafana.

jobs/report.py is that digest. Once a day it posts a single Discord message:

📊 **NDIF report** — 2026-08-21 01:20 → 01:50 UTC
**Uptime** 100.0% (2/2 checks)
**Requests** 175 received · 160 completed · 15 failed (8.6%)
**Users** 4 active · alice.chen@mit.edu (60), bob.rivera@stanford.edu (30), … · 58 unattributed
**Models** 2 used · openai-community/gpt2 (136), meta-llama/Llama-3.1-8B (39) · 1 HOT now
**Latency** p50 754 ms · p95 2414 ms
**Data** 49.1 MB in · 250.6 MB out

Two sources, deliberately

• Uptime from the connected_*.log datapoints the monitor cron already writes. The report probes nothing itself, so it cannot disagree with alerts that were already sent. An outage is a run of consecutive non-ok ticks measured first-bad to next-good, so it does not assume the monitor interval.
• Usage from InfluxDB, the durable metrics store. Loki is not consulted: every headline number is already a metric, and log retention is usually shorter than the window a daily report wants.

Two accounting decisions

Both because the obvious version is wrong, and both caught by running against real data:

• Failures are counted against received, not executed. A request that dies before reaching a replica never emits an execution_time point, so an executed-based rate hides it entirely — in testing that was 146 received against 139 executed, with the 7 missing requests invisible in the headline.
• Requests with no email tag are reported as unattributed rather than dropped. That is every request when auth is off, and otherwise the per-user counts silently fail to add up to the received count (117 of 146 in the same run).

It fails open: if InfluxDB is unreachable you still get an uptime-only report, which is exactly the moment you want one.

Configuration

Knob	Where	Default
schedule	NDIF_DASHBOARD_REPORT_CRON	0 0 * * *
window	NDIF_DASHBOARD_REPORT_WINDOW_HOURS / --window-hours	24
rows per top-list	report.top_n in config.json	3
message	messages.daily_report in config.json	see config.example.json
metrics source	NDIF_INFLUX_*	compose now sets these

Compose passes NDIF_INFLUX_* to the dashboard service, which previously had no telemetry access at all. --dry-run prints instead of posting.

build_report() returns a plain dict, so an endpoint could serve the same data to the UI later without a rewrite.

Testing

Verified end to end on the compose stack:

• Real traffic through the API (25 completed / 4 errored) lands in the report exactly, and the numbers reconcile: 160 completed + 15 failed = 175 received; 117 attributed + 58 unattributed = 175.
• Uptime validated against a synthetic day with a known 40-minute outage → reported 97.22% and longest 40m.
• Crontab installs after a rebuild with the Influx env passed through.
• A real webhook POST carries the right payload, with a custom template and top_n honoured.
• Empty-window, InfluxDB-down and no-connectivity-log paths all degrade gracefully.

Note for review

The uptime numbers only ever come from the monitor cron's own log, so a deployment that runs report without monitor will correctly say no connectivity data (is the monitor cron running?) rather than claiming 100%.

🤖 Generated with Claude Code