Incidents

Open an incident on a status page, post updates through the investigating → identified → monitoring → resolved lifecycle, and understand what can and cannot be changed after the fact.

Last updated August 5, 2026

An incident is the record your customers read when something is wrong. It has a title, an impact, a status, the services it affects, and an append-only timeline of updates.

This page covers incidents you write yourself. For the ones StatusOwl opens on your behalf, see Automatic incidents. For planned work, see Scheduled maintenance.

Lifecycle

Incidents move through four states:

State	When to use it
Investigating	The default for a new incident. Something is wrong and you have not confirmed why.
Identified	You know what broke. Say so — people stop guessing.
Monitoring	A fix is out and you are watching it hold.
Resolved	Cleared, and not expected to recur. The incident closes.

You do not have to walk all four. A quick fix can go Investigating → Resolved in two updates.

Impact

Each incident carries an impact that drives its badge and its position in the banner priority order:

Impact	Use it for
`none`	An informational note with no customer effect.
`minor`	Slow responses, partial degradation, one non-critical service.
`major`	A partial outage customers will notice.
`critical`	A full outage.

Opening an incident

Open the status page in the dashboard and click New Incident.
Write a title in plain language. "Login is failing for some users" beats "Auth gateway 5xx spike".
Pick the affected monitors — zero, one, or several.
Set the impact.
Write the first update: what you know, and what you are doing about it.
Click Open.

The incident is live on the public page immediately, with the title, impact badge, affected services and your first update.

Posting updates

From the incident's detail view, click Add Update:

Pick the new status.
Write the message. Keep it short, factual, and aimed at someone who does not work at your company.
Click Post.

The update appears on the timeline immediately. Posting an update with status Resolved closes the incident and stamps its resolution time. The page rollup returns to Operational once no incident is active and every visible component is up.

Incidents are append-only

Once an incident is created, its title, impact, start time and affected monitors cannot be changed. Individual timeline updates cannot be edited or deleted either. The only two operations are post another update and delete the whole incident.

If you got something wrong, post a correction as a new update — which is what you would want to do publicly anyway. If the incident should never have existed, delete it.

The public incident page

Every incident has its own URL at {your-page-host}/incidents/{uuid} — safe to link from an email, a support ticket or a tweet. It shows the impact and status pills, when the incident started, when it resolved, and the full update timeline newest-first.

Incidents belonging to another organization are not reachable from your page's hostname, even with a valid UUID.

Audit trail

Every incident and every update is written to the audit log, on every plan, with who did it and when.

What incidents do not do

They do not notify anyone. Opening, updating or resolving an incident changes the page. It does not send an email, a Slack message, or anything else. There is no subscriber list — visitors cannot subscribe to a page, and there is no subscribe form to build one. Both are on the roadmap.
They do not pause checks. Monitors keep checking throughout. To stop a monitor checking, use its own maintenance-mode toggle on the monitor.