ReliabilityBeginner
Trend daily service reliability
Did the newest complete days contain a broad reliability regression?
Use the larger service-event fact table to calculate daily volume, errors, and error rate while retaining the denominator beside the rate.
The dataset and query remain in this browser.
Published expected result
Daily service error rate
14.72%
2026-07-22
2.5%
2026-07-23
2.5%
2026-07-24
2.22%
2026-07-25
2.5%
2026-07-26
2.22%
2026-07-27
2.78%
2026-07-28
| service_day | operations | errors | error_rate_pct |
|---|---|---|---|
| 2026-07-22 | 360 | 53 | 14.72 |
| 2026-07-23 | 360 | 9 | 2.5 |
| 2026-07-24 | 360 | 9 | 2.5 |
| 2026-07-25 | 360 | 8 | 2.22 |
| 2026-07-26 | 360 | 9 | 2.5 |
| 2026-07-27 | 360 | 8 | 2.22 |
| 2026-07-28 | 360 | 10 | 2.78 |
How to read the query
- The UTC day is a visible reporting grain and the window ends with complete synthetic days.
- Volume and error count stay beside the rate so a change in denominator remains visible.
- The July 22 spike is a discovery signal; the next query must segment by service, release, region, or incident.
Decisions the SQL cannot make
- 1Choose a complete-bucket delay that matches ingestion latency.
- 2Set an objective and minimum volume before turning the rate into an alert.
- 3Separate scheduled maintenance and known test traffic with reviewed dimensions.