Incidents that open themselves.
A failed check opens the incident and attaches the cause. You acknowledge, post updates, and resolve. The status page follows along the whole way.
Down means an incident, not a log line.
When a monitor transitions to down, an incident opens on its own: start time, the failing check's error message as the cause, and a record of which checks were impacted. There is no "someone should file this" step between the outage and the timeline.
And when the check passes again, the incident resolves itself and posts an entry saying so. Nobody has to remember to close it at 4 a.m., and nothing stays red on the status page after the fix ships.
Acknowledge from wherever you got paged.
The first human response to an incident is one request. A POST to the acknowledge endpoint moves it from investigating to identified and posts a timeline entry, so the rest of the team can see someone is on it.
It is idempotent: acknowledging twice, or acknowledging an incident that already resolved, is a quiet no-op instead of an error. That makes it safe to wire into PagerDuty buttons, Slack slash commands, or a curl in your terminal history.
# investigating -> identified, plus a timeline entry
curl -X POST \
https://uptime-status.org/api/incidents/42/acknowledgeWhat incident management includes.
- Automatic opening a monitor going down opens an incident with the start time, the failing check's error as the cause, and the impacted checks recorded.
- Automatic resolution when the check passes again, the incident resolves itself and posts a timeline entry saying so. Nothing left open by accident.
- Four-status workflow investigating, identified, monitoring, resolved. Every incident starts at investigating, and each change lands on the timeline.
- One-step acknowledge a single POST from your alert tooling moves an incident from investigating to identified. Idempotent, so double-clicks are harmless.
- Update timeline each update records a message, a status, and a timestamp. Human posts carry an author, system posts do not pretend to.
- Searchable history filter incidents by status, search by cause, and sort by start or resolve time when you write the postmortem.
Planned work is not an outage.
A database migration on Saturday night should not read like downtime. Schedule a maintenance window with a title, description, start, and end, and your status page shows planned maintenance for that period instead of red bars and an incident.
Windows move from scheduled to active to completed on their own, checked every minute against the clock. Plans change? Cancel a window and it stays cancelled, no matter what its timestamps say.
Your status page already knows.
Incidents, their updates, and maintenance windows flow straight to your status page and its RSS feed, and subscribers get an email when an incident opens. There is no second system to keep updated while production is on fire.
Incident management, answered.
Do I have to create incidents by hand?
No. The moment a monitor transitions to down, an incident opens with the failure message attached as the cause. You can also create one through the API for anything the checks did not catch.
What are the incident statuses?
Investigating, identified, monitoring, and resolved. New incidents start at investigating, and every status change is recorded as a timeline entry, so the sequence of events survives the incident.
What does acknowledging do?
It moves the incident from investigating to identified and posts a timeline entry in one request. It is idempotent: acknowledging an incident that is already past investigating is a no-op, not an error, so it is safe to wire into alert buttons and chat commands.
What happens when the check recovers?
The open incident is resolved automatically and a system entry is posted to the timeline noting the recovery. If the incident deserves more words than that, you can still add your own updates afterward.
How do maintenance windows work?
Schedule a window with a title, description, start, and end. It moves from scheduled to active to completed on its own, checked every minute, and your status page shows it as planned maintenance instead of an outage. Cancelled windows stay cancelled.
Do my users see any of this?
As much as you publish. Incidents, their updates, and maintenance windows all render on your status page and in its RSS feed, and status page subscribers get an email when an incident opens.
Pairs well with.
Uptime monitoring
The checks that open these incidents: 30-second Pro intervals from six regions, with the evidence attached.
Learn moreStatus pages
Every incident and maintenance window lands on a branded page your users can check themselves.
Learn moreNotifications
Ten channels page the right people when an incident opens, and again when it resolves.
Learn moreStart monitoring in under 2 minutes.
No credit card required for the self-hosted, open-source version.