Returns active alert counts by severity and total resolved alert history
count. Requires read:systems permission.
Scope modes (selected by query params):
organization_id |
include |
Result |
|---|---|---|
| omitted | — | Caller's full hierarchy (recursive). For Customer it's just self. |
X |
omitted | Single tenant X only. Resellers/Distributors hold no alerts on their own tenant — those live on their customer tenants — so single-tenant queries on a non-leaf org typically return zero. |
X (repeated for multi) |
omitted | Union of all organization_id values passed. Each must be in the caller's hierarchy (Owner exempt). |
X (single or multi) |
descendants |
Each org_id is expanded to itself + its sub-tree (deduplicated). Use this to drill into one or more sub-trees. |
Active counts come from alerts_totals_by_org, a per-organization
pre-aggregated table maintained by the collect service's
AlertsTotalsRefresher cron (one Mimir round-trip per tenant every 60s,
off the user request path). The endpoint resolves the response with a
single SQL SUM scoped to the caller's hierarchy, so latency is
independent of how many tenants are in scope. The history total comes
from a single SQL query against alert_history scoped to the same set
of organization IDs.
When the freshest row in scope is older than 5 minutes (refresher
lagging or down), the response carries a warnings[] entry
(totals: stale data, oldest refresh Xs ago); counts are still served
as last known. DB errors on either table are likewise non-fatal and
surface as warnings[] entries.
Customer callers are always pinned to their own organization regardless
of organization_id/include.
Query parameters
-
Target organization ID(s). Repeat the param to pass multiple values (
?organization_id=A&organization_id=B). Optional for all roles except Customer (where it is ignored). Distributors/Resellers receive403if any value is not in their hierarchy. -
Set to
descendantstogether withorganization_idto expand each value to its full sub-tree (results deduplicated). Ignored whenorganization_idis omitted (the caller's own hierarchy is already used) and when the caller is a Customer.Value is
descendants.
curl \
--request GET 'https://collect.your-domain.com/api/alerts/totals' \
--header "Authorization: Bearer $ACCESS_TOKEN"
{
"code": 200,
"message": "alert totals retrieved successfully",
"data": {
"active": 42,
"critical": 42,
"warning": 42,
"info": 42,
"muted": 42,
"history": 42,
"warnings": [
"string"
]
}
}
{
"code": 401,
"message": "invalid token",
"data": {}
}
{
"code": 403,
"message": "insufficient permissions",
"data": {}
}