Audit release coverage before comparing regressions
Do product and API events cover the same releases well enough for a regression comparison?
List releases from both tables before calculating error rates. A release with no request data gets a null rate, so missing events cannot look like zero errors.
Expected result
API request coverage by release
| release | product_events | successful_product_events | api_requests | api_errors | api_error_pct |
|---|---|---|---|---|---|
| 2026.07.1 | 13 | 12 | 0 | 0 | — |
| 2026.07.2 | 8 | 8 | 10 | 6 | 60 |
How to read the query
- The release list includes every version found in either table.
- A release with no API requests keeps a null error rate, preventing absent coverage from appearing as zero-percent errors.
- Product event counts and API request counts expose whether the populations are comparable before a regression claim is made.
How to interpret the results
- 1Define which services and clients share a meaningful release identifier.
- 2Require minimum coverage and complete observation windows before comparing rates.
- 3Investigate instrumentation changes separately from product regressions.
Related lessons
Keep the result
Run this query on your own events
Create a free workspace only when you are ready to save the query, connect real events, and monitor the result. No credit card is required.