All features
Incidents

Incident management that opens, escalates and resolves from monitoring signals

A failing check becomes an incident the moment it trips your rule — debounced against flapping, grouped with related failures, assigned, acknowledged and resolved with a full audit trail, and mirrored to PagerDuty, Opsgenie, incident.io or Rootly if that's where your process lives.

Incident rules decide what deserves one: downtime after N failures from M regions, an anomaly of a given severity, a change of a given severity. Related failures collapse into one incident instead of ten; maintenance windows mute the monitors you're working on so planned work never pages the on-call; reminders repeat while it stays open.

Every incident carries its own timeline — the checks that opened it, the intelligence events detected around it, who acknowledged it and when, what resolved it — so the post-mortem writes itself.

  • Auto open & resolve from downtime, anomalies or change signals.
  • Debounce & grouping so flapping is one event, not fifty.
  • Maintenance windows with scheduled silence per monitor.
  • Incident-tool sync to PagerDuty, Opsgenie, incident.io and Rootly.
app.pulsetrace.app · incident management

How it works

  1. 1Set incident rules per monitor: confirmation thresholds, severity, destinations.
  2. 2A confirmed signal opens the incident and notifies; still-open reminders repeat on your interval.
  3. 3Acknowledge, assign and annotate in PulseTrace; recovery resolves it and notifies again.

Plan availability

Team and above.

Compare plans →

Questions about incident management

Does an incident page me twice if it flaps?
No — a monitor that recovers and fails again inside the debounce window reopens the same incident; reminders are the only repeats, on the interval you set.
Can I schedule maintenance?
Yes — maintenance windows mute alerts for chosen monitors during the window and are shown on the status page.