Incidents & Alerts
A failing monitor becomes an incident — a tracked, acknowledged, resolved lifecycle that your team can act on.
When an incident is created
- HTTP: three consecutive failed checks open one incident (dedup — no alert spam;
a single transient timeout never alerts). The consecutive threshold is configurable via
SIROPING_ALERT_CONSECUTIVE_FAILURES(default 3). - Heartbeat: no ping within
interval + grace→ Missed → incident. - SSL: certificate entering the warning window can open a warning incident.
Cooldown prevents alert repeats within the configured window.
Lifecycle
| State | Meaning |
|---|---|
| Open | Detected; nobody has confirmed yet |
| Acknowledged (ACK) | Someone clicked ACK — the team knows it's being handled (acknowledged_at/by recorded) |
| Resolved | Fixed; the monitor is healthy again (recovery alert sent if enabled) |
Team ACK
- ACK — claim the incident. Others see it's being handled.
- Resolve — close it after the fix. The recovery alert is sent to your channels.
- The header bell 🔔 shows all open alerts (Monitor / Cron / SSL) on every page — click to jump to the issue.
Where incidents appear
- Incidents page — filter by Monitor / Cron, search by name or reason.
- Dashboard — recent incidents with status.
- Reports — incidents and MTTR per project, per month.
Notifications
Alerts go out over Email, Telegram and Webhook — configured per workspace in Settings → Notifications, with a Test notification button. See Notifications.
FAQ
Why did one incident create many alerts? — Alerts are sent per state change (open / ack / resolve) plus configured escalation; dedup + cooldown cap repeats.
What if I miss the alert? — Open incidents stay visible in the bell 🔔 and on the Incidents page until ACK/Resolve.