Updated 25 October 2026 · By the Upcertain team
Opened only when a failure is confirmed
An incident opens after the monitor's confirmation checks all fail. Its start time is the first failed check, so the recorded downtime matches what users saw. It resolves on its own with the first passing check.
What an incident shows
- Cause: the status code, timeout, missing keyword, DNS failure, refused connection, certificate problem or missed heartbeat.
- The failed request and response: method, URL and headers sent, and the status, headers and the start of the body received.
- Timeline: detected, confirmed, alerts sent, acknowledged, comments, recovery.
- Duration, in the format the whole app uses:
9 m 19 s.
Acknowledge to stop the noise
Alerts link straight to the incident. Acknowledging it records who took it and stops repeat reminders on every channel. Owners, admins and editors can acknowledge; email alerts show the button only to people who can use it.
Notes and public updates
Team members add notes to the timeline: what they found, what they changed, who is on it. When customers need to know, post a status update from the incident to the status pages it affects; subscribers receive it by email.
Fewer, clearer alerts
- Alert grouping: when several monitors fail within a few minutes, owners and admins can have them arrive as one alert listing them all.
- Delays and reminders per monitor and channel: immediate in Slack, five minutes later by email, a reminder every 30 minutes until someone acknowledges.
- Maintenance windows keep planned work from opening incidents at all.
History and export
Search incidents by monitor, filter them by status or tag, sort them, and export them as CSV with the cause, status code, start, resolution, duration and who acknowledged each one. The REST API and the MCP server return the same records.