Incidents & maintenance

Open incidents on a status page, post status updates, schedule maintenance windows, and configure auto-incident creation from monitor failures.

Last updated May 9, 2026

When something breaks (or is about to break for a planned reason), your status page is where users find out what's happening. StatusOwl gives you two structured tools for that: incidents for unplanned issues, and scheduled maintenance for planned downtime. Both render on the public page above the component list, and both have a structured timeline of status updates.

Incidents

Lifecycle states

Incidents progress through four states, in this order:

State	When to use it
Investigating	Default for a new incident. You've seen something is wrong but haven't confirmed the cause.
Identified	You know what broke. Communicate the cause; users stop wondering.
Monitoring	A fix is deployed. You're watching to confirm it sticks before declaring victory.
Resolved	The issue is fully cleared and not expected to recur. The incident closes.

You don't have to march through all four — a quick fix can go Investigating → Resolved in two updates. The flow exists so you can match the cadence of a real on-call rotation.

Impact levels

Each incident carries an impact that determines the badge color and ordering on the page:

Impact	Visual
`none`	No badge — operational-level note
`minor` (default)	Yellow / amber
`major`	Orange
`critical`	Red

Pick minor for slow responses or non-customer-facing degradation, major for partial outage, critical for full outage. Impact is editable; bump it up if the situation gets worse.

Opening an incident

Open the status page in the dashboard and click New Incident.
Enter a title — short, plain English, no jargon. "Login is failing for some users" beats "Auth gateway 5xx spike".
Pick the affected components (zero, one, or many). Linking the right components is what flips the page rollup to Degraded alongside the incident banner.
Set the impact.
Write the first update message — what you know and what you're doing.
Click Open.

The incident is now live on the public page. Visitors see the title, impact badge, the linked components, and the first update.

Posting updates

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

Pick the new status (Investigating, Identified, Monitoring, or Resolved).
Write a message. Markdown is supported in the renderer; keep it short, factual, and oriented to a non-technical reader.
Click Post.

The update appears at the top of the incident timeline immediately. Posting an update with status Resolved closes the incident; the page rollup returns to Operational if no other incidents are active and all components are up.

Editing an open incident

The incident's title, impact, and linked components can be edited at any time — useful when the scope expands ("oh, this is also affecting the mobile app"). Existing updates are immutable; if you need to correct a factual error, post a new update with the correction.

Auto-incidents

StatusOwl can open a public incident automatically when a monitor attached to the status page logs 3 consecutive down results. Enable it per-page:

Open the status page → Settings tab.
Toggle Auto-create incidents on monitor failure.
Pick the default impact (minor, major, critical, or none) for auto-incidents.

When the threshold is hit, an incident is opened in the Investigating state with a generic title and a system-written first update. The incident is linked to the failing monitor. When the monitor recovers (next up result), the incident is auto-resolved with a closing update.

Auto-incidents keep the page honest without paging you for every flap. If you want to take over the narrative, edit the title and post a real update — the auto-resolve still fires when the underlying monitor recovers.

One auto-incident per monitor at a time

If a monitor is already on an open auto-incident, the system won't open a second one — flappy monitors don't spam your page. The same monitor attached to two pages can have an open auto-incident on each, scoped per page.

Scheduled maintenance

For planned work — deploys, migrations, vendor maintenance — open a scheduled maintenance entry instead of an incident. Maintenance renders on the page with its scheduled start and end times, and signals to visitors that downtime is intentional.

Maintenance lifecycle

Maintenance windows have three states:

State	When
Scheduled	Created in advance. Shown on the page with its scheduled start time.
In progress	The work has begun. Auto-stamps `actual_start_at` when you transition.
Completed	The work is finished. Auto-stamps `actual_end_at`.

Scheduling a window

Open the status page → click New Maintenance.
Enter a title and an optional description (markdown supported).
Set the scheduled start and scheduled end times. End must be after start; the dashboard validates this.
Pick the affected components.
Click Schedule.

The window appears on the public page in the upcoming section. As the start time approaches, surface it more prominently — link to it from release notes, customer emails, or your in-app changelog.

Posting maintenance updates

Maintenance has the same update-timeline pattern as incidents. Use it to post:

"Maintenance has begun" (transitions to In progress).
"Phase 2 complete, moving on to phase 3" (status stays In progress).
"Maintenance complete, all systems normal" (transitions to Completed).

Both incidents and scheduled-maintenance entries render with the same update-timeline UI on the public page; visitors can tell them apart by the badge styling.

Maintenance and monitor alerts

A scheduled-maintenance entry on a status page documents the work for public visitors but does not automatically suppress monitor alerts — those gates are independent. To stop your own integrations from paging during the work, set the affected monitors' maintenance_mode flag in the dashboard before the window starts. We're tracking native suppression between scheduled-maintenance and monitor alerts on the roadmap.

Per-page quotas

There's no hard cap on the number of incidents or maintenance entries per page. Only the freshest entries — open incidents, in-progress maintenance, and the last few resolved entries — are displayed by default; visitors can paginate into history.