Incidents

What happens after a Maple alert rule fires: how an incident opens, renotifies, waits on missing data and resolves, what each notification contains, and where to see incidents.

An incident is one period during which an alert rule is breaching. Maple opens it, notifies the rule’s destinations, repeats the notification while the breach continues, and resolves it when the signal recovers.

A rule that evaluates several groups (several services, or a Group by) keeps a separate incident for each group. One slow route opens one incident. It does not open or resolve the others.

Lifecycle

Maple checks every enabled rule once a minute. Each check is breached, healthy or skipped (too few samples, or no data).

Step	When it happens	Notification
Open	The rule breaches on Breaches to fire consecutive checks.	`trigger`
Renotify	The incident is still breaching and Renotify (min) minutes have passed since the last notification.	`renotify`
Resolve	The rule is healthy on Healthy to resolve consecutive checks.	`resolve`

Skipped checks do not move the incident either way. The breach and healthy counters keep their values until the next check that has enough data.

An incident has two statuses, open and resolved. A resolved incident stays resolved. If the rule breaches again later, Maple opens a new incident.

Flapping

If a rule resolves and then opens a new incident for the same group within its Renotify (min) interval, Maple opens the incident without sending a trigger. The matching resolve is not sent either. This stops a signal that hovers around the threshold from sending a notification every few minutes.

Waiting on data

A breach can stop appearing because the problem is fixed, or because the service stopped sending telemetry. Before it resolves an incident on an empty window, Maple checks whether the service’s traffic is still arriving. It compares the current window with the traffic just before the incident opened, and with the same time the day before.

If Maple cannot confirm the traffic, the incident stays open and shows Waiting on data in place of its current value. Hovering the badge shows why:

Situation	Resolves
The service stopped reporting.	When telemetry returns, or after 6 hours.
Traffic fell below half of its usual level.	When data returns, or after 3 windows (at least 30 minutes).
Raw span counts fell while sample-weighted counts did not (sampling changed).	When the signal settles, or after 6 hours.
Maple could not verify telemetry for the service.	On the next successful check.

If the breach reappears while the incident is waiting, it goes back to firing. If the time limit passes without a breach, Maple resolves the incident and says so in the resolve reason.

What a notification contains

The built-in format carries:

The rule name and the event (Triggered, Re-notification, Resolved or Test).
The severity (Warning or Critical).
The signal, the observed value and the threshold it was compared against.
The group, or all for an ungrouped rule.
The evaluation window.
A link to the alert in Maple and a link to ask Maple AI about it.

A rule’s Message template replaces the title and body for Slack, Discord, Telegram and PagerDuty destinations. Email, webhook and Hazel destinations use the built-in format. PagerDuty receives a stable dedup_key so the trigger and resolve land on the same PagerDuty incident. The webhook payload is in the alert webhooks reference.

If a delivery fails with an error that can be retried, Maple retries it up to 5 attempts, with a delay that doubles from 1 minute up to 15 minutes.

Where to see incidents

Alerts → Overview. When anything is firing, Active incidents lists every open incident with its Severity, Rule, Group, Current value, Duration and Last notified time. The summary cards count rules that are Firing, Needs attention, Healthy and Disabled.
The rule’s page. Click a rule or an incident row. The Overview tab charts the signal with the threshold and lists recent checks. The History tab lists past incidents, filterable by All, Fired and Resolved, with Total triggered, Avg resolution and Top contributors.
MCP. list_alert_incidents and get_incident_timeline on the MCP server return the same data to an AI assistant.

Troubleshooting

An incident is stuck on Waiting on data. The service stopped sending the telemetry the rule reads. Check the service under Traces. The incident resolves on its own once data returns or the time limit passes.
An incident opened but nobody was notified. Check that the rule has destinations and that none is marked Disabled on the Destinations tab. A re-opened incident inside the renotify interval is silent by design (see Flapping).
Too many notifications. Raise Renotify (min), or raise Breaches to fire and Healthy to resolve on the rule.

Next steps

Alert rules: the settings that control when incidents open and resolve.
Notification destinations: where notifications go.
Alert webhooks reference: the webhook payload.