Incidents & Correlation

How Incidents Work

RawMon automatically creates an incident when a monitor transitions to DOWN status. The incident tracks the full lifecycle from detection to resolution, including timestamps, duration, and related alerts.

Incident Lifecycle

1. Detection — A monitor fails its check (after retries). Status changes from UP to DOWN.
2. Incident Created — RawMon records the start time, monitor details, and initial status.
3. Escalation — Push notifications follow the escalation schedule (5m, 15m, 1h, 4h).
4. Resolution — The monitor returns to UP. RawMon records end time and calculates total downtime.

Only DOWN status creates incidents. WARNING status (e.g., certificate expiry approaching) does not trigger incident creation — it only sends a notification.

Cross-Source Correlation

When you monitor the same service from multiple sources (e.g., native HTTP check + UptimeRobot + Uptime Kuma), RawMon correlates incidents by hostname. Instead of creating three separate incidents for the same outage, it links them to a single correlated incident.

Correlation works across all monitoring modes: native, Kuma, SaaS providers, and push relay webhooks. The hostname is extracted from the monitor URL or configuration.

Incident Timeline

Each incident maintains a timeline of events:

• Status changes — Every transition (DOWN, UP, WARNING) is recorded with a timestamp.
• Alerts sent — Each push notification linked to the incident appears in the timeline.
• Manual notes — You can add free-text notes to document investigation steps, root cause, or remediation actions.

Severity

Incident severity is determined by the monitor's status and the number of affected monitors in a correlated group:

• A single monitor DOWN creates a standard incident.
• Multiple correlated monitors DOWN indicates a broader outage.

Resolution Flow

Incidents resolve automatically when the monitor returns to UP status. The resolution records:

• End time and total downtime duration
• Recovery alert sent via push notification
• Badge count updated immediately

You can also view resolved incidents in the Incidents tab, filtered by date range or monitor.

Incident Deduplication

The incident pipeline includes guards against duplicate creation:

• Grace period — A brief window after resolution before a new incident can be created for the same monitor, preventing flapping from generating noise.
• Webhook dedup — Push relay alerts are deduplicated by alert ID to prevent the same external alert from creating multiple incidents.
• Concurrent check guard — On Android, the foreground service deduplication prevents multiple simultaneous check cycles from racing to create incidents.

Viewing Incidents

The Incidents tab shows all incidents sorted by start time (most recent first). Each incident card displays the monitor name, status, duration, and source. Tap an incident to see the full timeline, linked alerts, and notes.