Alerts

Incidents & On-Call → Alerts is the board: everything currently firing, everything recently resolved, and what was done about it.

The list

Each row carries the severity, the rule it came from, the subject, how long it has been firing, and whether anybody has acknowledged it.

Filters worth knowing:

Acknowledging

Acknowledging says a human has seen this and is dealing with it. It stops escalation from paging the next person, and it shows on the board so nobody duplicates the work.

It does not resolve the alert and does not silence it. The condition is still true; you have just taken responsibility for it.

The alert detail page

Opening an alert gives you, in order:

1. What fired — the condition, the measured value, the threshold that decided, and the window it was measured over.
2. The history — a sparkline of readings around the event, so you can see whether this was a step change or a spike.
3. Notification delivery — which channels it went to and what happened. This panel has four states and they are not the same: delivered, in flight, failed (retrying), and gave up. See Notification delivery.
4. The rule — a link back to what produced it, or a note that the alert is not tied to a rule (auto-generated or ingested by webhook).
5. What changed — correlated deploys, config changes and flag flips from around the same time. It says what changed, never what caused it.

Silencing one alert

A silence stops notifications for a specific alert or fingerprint without changing the rule. Use it when you already know and are working on it.

For planned work, use a maintenance window instead — it covers everything in scope rather than one alert at a time, and it is recorded as planned rather than as somebody muting a page.

Grouped alerts

When one transition affects many subjects, AccelerUp raises a group alert that stands for all of them and resolves the individual ones.

The group closes on the last recovery, not the first. A group that closed when the first subject recovered would mark an ongoing outage as resolved.

Resolving by hand

An alert can be resolved manually. This is for the case where the condition is genuinely over but the source can no longer measure it — a deleted service, a decommissioned host. It is recorded as a manual resolve, with who did it.