Managing monitor incidents

Once a monitor exists, day-to-day work with it is mostly these five actions.

Run now

Forces an immediate check instead of waiting for the underlying query’s next scheduled refresh. Goes through the same run pipeline a schedule would use, so it respects the query’s normal freshness handling — it’s “check right now” for whoever’s looking at an incident, not a way to bypass the query’s own execution path.

Mute / unmute

Muting a monitor silences its notifications entirely, indefinitely, until you explicitly unmute it — there’s no auto-expiry. Use mute for a monitor you want to keep around and keep checking (its state still updates normally) but don’t want paging anyone right now, e.g. during planned maintenance on the underlying system.

Snooze

Snooze silences notifications for a fixed number of minutes, then automatically resumes — set it once with a duration and it lifts itself, no separate “unsnooze” step needed. Snoozing for 0 or a negative number of minutes clears any active snooze immediately instead, which is how a “cancel snooze” action works from the same endpoint.

[!TIP] Reach for snooze over mute when you know the noisy period has a clear end (a deploy window, a known temporary data gap) — you won’t have to remember to come back and unmute it.

Acknowledge

Acknowledging a currently triggered monitor is a lightweight “I’ve got this, no need to keep escalating” signal — any teammate who can see the monitor can acknowledge it, not just its owner. It stops further escalation steps from firing, but it does not mute the monitor and does not suppress the next real state-change notification: if the monitor clears to ok and then triggers again, that’s a new incident, and the acknowledgment is cleared automatically along with it. You can’t acknowledge a monitor that isn’t currently triggered, or one that’s already been acknowledged.

Delivery history

Every notification attempt a monitor has made — which destination, which subscription, whether it succeeded, and any error — is recorded and viewable per monitor, newest first, capped at the most recent 50. Use it to confirm a notification actually went out, or to diagnose why a destination stopped receiving alerts (an expired webhook, a revoked API key, and so on).

[!NOTE] You can also manually re-send a notification to one specific subscription regardless of the monitor’s current state — useful for testing a destination you just configured, or pinging a subscriber mid-incident without waiting for the next state change.

Where to go next

• Alerts overview — the state machine and rearm behavior these actions sit on top of.
• Notification destinations — what a subscription is actually notifying.
• Escalation — the step chain acknowledging stops.