Incident tracking
Every outage written down as it happens, on its own timeline.
An outage that writes itself down
When a check fails past its confirmation streak, UpCheck opens an incident on its own. No one has to notice first and start a doc; the record exists from the moment the outage does.
From there it keeps a timeline, detected, identified, monitoring, resolved, stamped with the times and what each check saw. When the service recovers, the incident closes itself and the duration is already there. The first half of the post-mortem is written before anyone opens their laptop.
The alert and the incident are one event
The page you get and the incident that opens are the same thing seen twice, so they never disagree. The alert links straight to the timeline, and the timeline is what your status page reads from.
That means one source of truth for an outage: what paged you, what your users saw, and what goes in the review are all the same record.
Decide what opens one
An incident opens on a confirmed failure, not a single blip, because the same confirmation streak that holds back a noisy alert holds back a noisy incident. Recovery has to hold too: a service that flaps up for one check and back down doesn't close the incident and reopen a new one.
Nothing here needs configuring to start. Create a monitor and its incidents are already being kept.
Build trust with
public status pages.
Every monitor can back a public status page, so the people asking whether you're down can answer it themselves. Ninety days of history per monitor, on your own domain.
Planned downtime
shouldn't page anyone.
Schedule a window and the checks keep running, but the alerts stay quiet and the uptime maths doesn't count it against you. One-off or recurring, per monitor.