Repository navigation
alert_transitions API returns incomplete transitions (raises missing) #1155
Description
Summary
POST /api/v2/spaces/{spaceId}/rooms/{roomId}/alert_transitions returns only part of the alert transitions in the requested window. Transitions into WARNING/CRITICAL are missing far more often than transitions back to CLEAR, so any count of "alerts raised" built on this endpoint undercounts, and raise/clear pairs cannot be matched.
Evidence
Same space and room, same time windows, payload { "after": <s>, "before": <s> } (no node or chart filters):
| Window | Source | Result |
|---|---|---|
| last 3h | alert_transitions (frontend endpoint) |
1,098 transitions in the room; for all azure_monitor.* alerts together: CLEAR→CRITICAL 5, CRITICAL→CLEAR 15, CLEAR→WARNING 9, WARNING→CLEAR 12 |
| last 3h | MCP get_alert_transitions, one single azure_monitor.* alert |
36 transitions for that alert alone: CLEAR→CRITICAL 18, CRITICAL→CLEAR 18 |
| last 24h | alert_transitions (frontend endpoint) |
6,942 transitions in the room; for azure_monitor.* alerts: CLEAR→CRITICAL 7 vs CRITICAL→CLEAR 27, CLEAR→WARNING 10 vs WARNING→CLEAR 43 |
One alert alone has more raises in 3 hours than the endpoint returns for all alerts of that collector, and in every window the endpoint returns many more clears than raises.
Other observations
- The response has no
old.duration, so time spent in the previous state cannot be read directly. - Adding an unsupported
contextsfield to the payload changes the result to a 100-row, unfiltered response instead of being ignored or rejected.
Expected
All transitions in the window are returned (or the response says it is truncated and supports paging), and request fields that are not supported are rejected or ignored without changing the result.
Impact
Frontend cards that count raised alerts over a time range (alerts raised over time, raised/resolved counts, mean time to resolve, noisiest resources) undercount, especially for flapping alerts.
Activity