Connect API failures to customer impact
Which plans and recurring revenue were exposed to API failures during the incident?
Reduce request failures to one row per account before joining commercial context, preventing high-volume customers from being counted repeatedly.
Published expected result
Recurring revenue exposed to API failures
| plan | accounts | impacted_accounts | impacted_pct | mrr_exposed_usd |
|---|---|---|---|---|
| growth | 2 | 2 | 100 | 4,200 |
| business | 1 | 1 | 100 | 1,200 |
| starter | 2 | 1 | 50 | 199 |
| free | 1 | 0 | 0 | 0 |
How to read the query
- Request rows are reduced to one account-level impact result before the commercial join.
- The left join preserves accounts with no errors so the impacted percentage has the correct denominator.
- Exposed MRR describes incident scope; it does not claim that revenue was lost.
Decisions the SQL cannot make
- 1Define the incident window and affected routes before calculating account impact.
- 2Use privacy-approved identifiers and restrict access to commercial dimensions.
- 3Keep exposed, at-risk, refunded, and actually lost revenue as different measures.