Calculation rules and validation checksUse these to reconcile the dashboard against the weekly reports and metric JSON.
Week Axis
The selected timeframe uses the last 4, 8, or 13 canonical weekly buckets available in the metric store.
Weeks before the first real report are not invented; missing in-range reports stay visible as gaps, not zeroes.
A chart point with a gap means the source family is missing for that week.
Delivery
Delivered work counts completed bugs plus Delivery items split by Jira type: Story, Task, and Improvement.
Evidence split in weekly reports is exclusive: MR-backed + Direct commits + Jira-only = Total. Carryovers are an overlapping subset.
Leaderboard churn = added + deleted. Open person trends or the evidence drawer when you need the added/deleted/net split.
Tests
Daily suite runs count scheduled daily regression pipelines once per pipeline, not individual test cases.
Daily pass/fail uses the whole pipeline result: one failed category makes that daily pipeline count as one failed run.
Smoke attempts count individual smoke jobs in production pipelines, currently Frontend and University, not individual smoke test cases.
Category failures count failed test cases/specs from daily regression artifacts inside Billing, Web, Frontend, and Library; they are not failed pipeline counts.
People And Sources
People leaderboard sums source-backed person delivery series across the selected weeks; team charts stay overall.
Person counts may exceed team totals when one Jira item has multiple source-backed contributors.
Open the JSON below to audit exact points. Empty source_json means that week was recovered from rendered HTML fallback.
Alert metrics come from the production reliability dashboard JSON when available, or its embedded HTML data as a fallback.
The aggregated alert list groups by impacted service/resource across the selected 4, 8, or 13-week window and shows alert families as evidence.
Application alerts are Slack/application alert rows. Infrastructure alerts are AWS/SNS-style email rows, including ALARM and OK/recovery state changes.
Active AWS alarms are separate: they count only infrastructure alarms whose latest weekly state is still ALARM.
Pingdom events are event counts. Pingdom downtime is the summed Down/Slow duration in minutes, so the numbers can match by coincidence while meaning different things.