Most status pages are only as fast as the person who remembers to update them.
That person is asleep, or in a meeting, or already busy fixing the thing. StatusOwl posts the first update from the checks themselves. Three consecutive failures opens the incident. The first success closes it.
On every plan, including Free.
We have automatically detected that one of the monitors attached to this status page is failing. Our team is investigating.
- Opened
- 02:12:00 UTC
- Opened by
- Checks
- Impact
- Major
- Status
- Investigating
- Failed checks
- 3
- Updates
- 1
Nobody logged in to write this
What actually happens, in order.
No heuristics, no model, no confidence score. A counter, a threshold, and one write to your page.
Three consecutive failed checks
The monitor has to fail three checks in a row. Any successful check in between resets the counter to zero and the sequence starts over.
An incident opens on the page
StatusOwl creates the incident at the page's configured default impact, sets it to investigating, seeds an automatically detected first update, and links the failing monitor as the affected service.
The first success resolves it
On the first passing check after the streak, a recovery update is posted, the incident is marked resolved and the resolved time is stamped.
Fourteen minutes, step by step.
A monitor checked every 30 seconds starts failing at 02:11. This is every step the page takes on its own, and every step it deliberately does not take.
- 02:10:30Check passes
The monitor answers normally. The page says operational. The failure counter is at zero.
- 02:11:00Failure 1 of 3
The check fails. The counter goes to one. Nothing is posted to the page and nobody is told, because one failed check is not an outage.
- 02:11:30Failure 2 of 3
The check fails again. The counter goes to two. Still nothing is posted.
- 02:12:00Failure 3 of 3 — thresholdOpens
The third consecutive failure crosses the threshold. StatusOwl opens an incident on every page this monitor is attached to that has automatic incidents turned on.
- 02:12:00Incident published
The incident opens at the impact level the page is configured to use, with status investigating and a first update stating that the failure was automatically detected. The banner goes up and the affected service is marked on the page.
- 02:12:30Failures continueSuppressed
Checks four, five and six also fail. No second incident is opened. While an automatically created incident for this monitor is still open, further failures are suppressed on that page.
- 02:24:00First successful checkResolves
The monitor answers normally again. StatusOwl posts a recovery update, sets the incident to resolved, and stamps the resolved time. The banner clears.
- 02:24:00Filed into history
The incident moves into past incidents with its whole timeline intact, and the outage is visible in the 90-day uptime bar for that service.
A single blip should not post an incident.
One failed check is not evidence of an outage. It is one slow response, one dropped packet, one redeploy landing mid-request.
A wrong incident costs more than a late one
Your status page is the one thing customers are told to trust when they cannot reach you. If it cries outage over a single timeout, the next real outage gets ignored. Three consecutive failures is a low enough bar to be fast and a high enough one that transient noise never reaches your users.
The counter resets on any success
Two failures then a pass is not an incident. The streak has to be unbroken, so a service that is merely flapping does not accumulate its way over the line across an afternoon.
The cost is bounded and knowable
Three checks is a fixed, published delay you can multiply by your check interval — not an opaque confidence threshold that behaves differently on a Tuesday.
Detection speed is just your check interval, times three.
Because the rule is a plain counter, you can work out the worst case yourself. Your check interval comes from your plan.
| Plan | Check interval | Failures needed | Incident opens within |
|---|---|---|---|
| Free | 3 min | 3 | 9 min |
| Starter | 60 sec | 3 | 3 min |
| Growth | 30 sec | 3 | 90 sec |
| Scale | 30 sec | 3 | 90 sec |
Worst case, measured from the moment the service starts failing: up to one interval before the first check catches it, then two more intervals to reach the threshold. If the failure begins just before a scheduled check it is faster than that.
One banner, in a fixed order.
Several things can be true at once — planned work, a declared incident and a failing check. The page shows one of them, and it always picks in the same order.
- 01Maintenance in progress
A maintenance window that has been moved to in progress takes the banner ahead of everything else, so planned work is never presented to your users as an outage.
- 02Highest-impact active incident
Otherwise the banner shows the open incident with the highest impact — critical, then major, then minor — along with its most recent update, and links to the public incident page.
- 03Auto-detected outage
If a monitor on the page is failing and no incident has been declared at all, the page still says so on its own rather than sitting there claiming everything is fine.
04 — none of the above. No banner, and the page reads operational.
Off by default. On when you say so.
Automatic incidents are a per-page switch, not a platform-wide behaviour. Two pages can watch the same monitor and behave differently.
A switch per page
Turn automatic incidents on for the page where it belongs and leave it off on the others. A public marketing status page and an internal one can disagree about this.
Your default impact
Choose the impact an automatic incident opens at — none, minor, major or critical. That level is what decides its place in the banner order against any other open incident.
Only attached monitors
Only monitors you have added to the page can open an incident on it. A staging check nobody has attached stays out of your customers’ view entirely.
Duplicates suppressed
While an automatically created incident for a monitor is still open, more failures on that monitor will not open a second one on the same page.
Per page, not per account
One failing monitor attached to three pages opens one incident on each, each at that page’s own configured impact.
Read moreYours to overrule
An automatic incident is an ordinary incident. Post your own update on top of it with a real explanation, resolve it yourself, or delete it.
It updates the page. That is all it updates.
This is the part most vendors would leave to you to discover. We would rather you knew before you signed up.
An automatic incident publishes to your status page and nowhere else. There is no subscribe form on StatusOwl status pages and no subscriber list in the dashboard, so opening an incident does not email, text or push anything to your users. They see it when they load the page.
A failing HTTP, ping or TCP check does not page anyone. The six notification channels are real and in production, but today the only thing that dispatches to them is a Watch Owl server-metric alert rule. If you need to be woken up when a site goes down, keep the tool that does that until we ship this — it is the thing we are working on now.
The things people ask before switching.
- What opens an automatic incident?
- Three consecutive failed checks on a monitor that is attached to a status page with automatic incidents turned on. On the third failure StatusOwl opens an incident on that page at the impact level the page is configured to use, sets its status to investigating, and posts a first update saying the failure was automatically detected.
- What counts as a failed check?
- A response outside the status codes you told the monitor to expect, a request that exceeds the timeout you set, or a connection that fails outright. For ping and TCP it means no reply within the timeout. The rule is the same regardless of check type: three in a row.
- What if the monitor recovers between failures?
- The streak breaks and the counter goes back to zero. Failure, failure, success, failure, failure never opens an incident.
- Can I still write my own update on an automatic incident?
- Yes, and you should. The seeded first update says a monitor is failing and someone is looking. Posting your own update on top of it tells your customers what is actually wrong, and the automatic recovery still resolves the incident when the checks pass again.
- Does maintenance stop automatic incidents opening?
- No. A maintenance window changes what the banner shows while it is in progress, but it does not pause checks or hold back automatic incidents. The only thing that stops a monitor being checked is the per-monitor maintenance-mode toggle.
- Does an automatic incident notify anyone?
- No. It publishes to the status page and nothing else. StatusOwl has no status page subscriber system, and a failing HTTP, ping or TCP check does not currently dispatch to Slack, email or a webhook. Both are on the roadmap and neither is shipped.
- Does it work on the Free plan?
- Yes. Automatic incidents are on every plan. The plan changes how often the monitor is checked, which is what decides how quickly the third failure arrives.
Incident updates
The manual side: impact, status, affected services and an append-only timeline your customers can read top to bottom.
Read moreScheduled maintenance
Announce planned work before it starts, and take over the banner while it is running.
Read moreUptime checks
HTTP, ping and TCP checks from 30 seconds — the checks that feed all of this.
Read moreLet the checks write the first update.
Free forever on one page, with your own domain and automatic SSL. No credit card.