Automatic incidents

Three consecutive failed checks opens an incident on your status page. The first successful check resolves it. How the threshold works, what gets written, and what it does not do.

Last updated August 5, 2026

Most status pages are only as current as the last person who remembered to update them. StatusOwl runs the checks behind your page, so it can open the incident itself.

The rule is deliberately boring: three consecutive failed checks on an attached monitor opens an incident. The first successful check resolves it.

Turning it on

It is off by default, and it is set per page.

Open the status page → Settings.
Turn on Auto-create incidents on monitor failure.
Pick the default impact — none, minor, major or critical. New pages default to minor.

Only pages that are Active and have the toggle on will open incidents. A page with the toggle off is unaffected, even if it shares monitors with a page that has it on.

The threshold

Every monitor carries a running count of consecutive down results. Any up result resets it to zero.

Result	Counter	What happens
1st failure	1	Nothing. The component reads `down`.
2nd failure	2	Nothing.
3rd failure	3	An incident opens on every eligible page.
4th failure and beyond	4, 5…	Nothing new. No duplicate incidents.
First success	0	A recovery update is posted and the incident resolves.

Three in a row, not three within a window. One flaky check followed by a success never opens anything. How long three failures take depends on your check interval — 90 seconds on a 30-second interval, 9 minutes on Free's 3-minute interval.

Why three, and why not a vote

Three consecutive failures is a simple, explainable rule, and an explainable rule is what you want in the thing that publishes to your customers. It is a consecutive-failure count, not a quorum across regions — every monitor checks from a single region today (see Monitoring regions), so there is nothing to take a vote among.

What gets written

When the threshold trips, StatusOwl opens an incident on each eligible page with:

Title — "Automated detection: monitor failure".
Impact — the page's configured default impact.
Status — investigating.
Affected services — the monitor that failed.
First update — "We have automatically detected that one of the monitors attached to this status page is failing. Our team is investigating."

It is marked as automatically created, which is how duplicate suppression and auto-resolution find it later.

Recovery

On the first up result after a failure streak, every open automatic incident for that monitor is resolved — across every page it appears on. A closing update is posted first:

The affected monitor has recovered. Automatically marking this incident as resolved.

The incident's resolution time is stamped, and the page rollup returns to Operational once nothing else is outstanding.

Duplicate suppression

If a monitor already has an open automatic incident on a page, a further trip of the threshold will not open a second one. A monitor that flaps for an hour produces one incident, not twelve.

The same monitor attached to two different pages can have its own open incident on each — the suppression is per page, so one customer's page is never suppressed by another's.

Taking over the narrative

An automatic incident is a normal incident. You can post your own updates onto it, and you should — "Automated detection: monitor failure" tells your customers nothing useful.

Note that the title, impact and affected services of any incident are fixed at creation and cannot be edited, including automatic ones. If the generic title is unacceptable for a serious outage, delete the automatic incident and open one you have written yourself. Automatic resolution only applies to incidents that were opened automatically.

Separately from all of the above, when a monitor attached to a page is down and no incident has been declared, the page shows an automatically-detected outage banner. It exists so a page never claims everything is fine while a component is visibly red. Banner priority is: in-progress maintenance first, then the highest-impact active incident, then this banner.

An automatic incident notifies nobody

This feature updates the page. It does not page you, email you, or post to Slack. There is no subscriber list on status pages, and a failing HTTP, ping or TCP check does not dispatch to any notification channel today — the only thing that does is a Watch Owl host-metric alert rule.

Uptime alerting is the thing being built right now; see the roadmap. Until it ships, an automatic incident is a way to keep customers informed, not a way to find out.