The written record your customers read while they wait.
Declare the incident, say who it affects and how badly, then work it from investigating through to resolved. Every update is timestamped, public the moment you post it, and kept afterwards.
Unlimited incidents on every plan, including Free.
Elevated webhook delivery failures
- Investigating14:02 UTC
We are seeing elevated error rates on webhook delivery. We are investigating and will update in 15 minutes.
- Identified14:19 UTC
The cause is a connection pool exhaustion in the delivery worker after this morning's deploy. We are rolling back.
- Monitoring14:41 UTC
The rollback is complete and delivery has caught up on the backlog. We are watching queue depth before calling this resolved.
- Resolved15:10 UTC
Delivery has been stable for 30 minutes and the backlog is clear. No webhooks were dropped; delayed deliveries were retried.
Affected · Webhooks · API
Four levels, and they mean something.
Impact is not decoration. It sets the colour and severity of the banner, and when more than one incident is open it decides which one your users see at the top of the page.
| Level | What it means | Typical use |
|---|---|---|
| None | Something your users should know about that is not degrading service. | A provider advisory, a third-party outage that does not affect you yet, a post-mortem note. |
| Minor | A part of the product is slower or flakier than it should be. | Elevated latency, a background job backing up, one non-critical endpoint erroring. |
| Major | A significant piece of the product is unusable for a significant number of people. | One region down, sign-in failing, webhook delivery stopped. |
| Critical | The product is down, or the failure is severe enough that everything else is noise. | Total outage, data path unavailable, a security event you are disclosing. |
Ordering runs critical, major, minor, none. An in-progress maintenance window outranks all of them — see the banner order.
Investigating, identified, monitoring, resolved.
Each update you post carries one of these four statuses, and the status of the newest update is the status of the incident. There is no separate button to press.
Investigating
We know something is wrong and we do not yet know why. The first update almost always starts here — it is the one that stops your support queue filling up.
Identified
The cause is known and a fix is in progress. This is the update that tells customers whether to wait ten minutes or make other plans.
Monitoring
The fix is out and you are watching to see it hold. The incident stays open and stays on the banner.
Resolved
Posting an update with this status transitions the incident, stamps the resolved time, clears the banner and files it into your page history. It also closes the incident for good — nothing more can be posted to it.
You are not forced to walk them in order. If you know the cause immediately, open the incident at identified. Going backwards is fine too — a fix that does not hold can be followed by another investigating update. The one door that closes is resolved: once you post a resolved update, that incident accepts no further updates, and a regression afterwards is a new incident.
Five fields, then you are publishing.
An incident belongs to one status page. You write the first update as part of creating it, so nothing ever goes up with a title and no explanation underneath.
- Title
- What your customers will see and search for. Up to 255 characters.
- Impact
- None, minor, major or critical.
- Affected services
- Pick any monitors on this page. They are marked as affected while the incident is open.
- Start time
- Defaults to now. Backdate it when you are writing up something that began before you noticed.
- First update
- A status and a message, up to 4,000 characters. This becomes the first entry on the public timeline.
An incident log is a record, so it behaves like one.
These are real constraints, not features we are dressing up. Read them before you decide, because they change how you write.
The incident record is fixed at creation
Title, impact, start time and affected services are set when you declare the incident and there is no edit form afterwards. Write the title as the thing your customers will search for, and pick the impact you can defend an hour later.
Updates are append-only
An update cannot be edited or deleted once posted. If you get something wrong, you correct it the way you would in any public incident log: by posting another update that says so. The mistake and the correction both stay visible.
The only escape hatch is deleting the whole incident
There is no partial undo. You can delete an entire incident — which removes it and its timeline from the public page — and that deletion is audit-logged like every other change.
Past incidents show the 25 most recent
The incident history on a status page lists the 25 most recently started resolved incidents. Older ones are still in your account and their public incident pages keep working; they just stop appearing in the list on the page.
If you need to edit a published incident in place, StatusOwl is not the right tool today and we would rather you found that out here. What you get in exchange is a timeline nobody can quietly rewrite after the fact — including us.
Every incident has its own page.
A link you can paste into a support reply, a customer email or a ticket — and it keeps working long after the banner comes down.
A permanent URL
Each incident lives at its own address on your status page, with the impact, the status, when it started, when it resolved, and the full timeline in order.
In the page history
Resolved incidents drop off the banner and into the page’s incident history, alongside the uptime bars that show the same outage as a red day.
Scoped to your page
An incident URL only resolves on the status page it belongs to. Guessing an identifier from someone else’s page returns nothing.
Live without refreshing
Open pages poll every 30 seconds, so an update you post appears to everyone already sitting on the page without them reloading.
Read moreAudit-logged
Creating an incident, posting an update and deleting one are all recorded with who did it and when — on every plan, including Free.
Read moreOr opened for you
Three consecutive failed checks can open the incident and seed the first update automatically, then resolve it on recovery.
Read morePosting an update publishes it. It does not send it.
The gap between those two things is the biggest one in the product right now, and it is the first thing you should weigh.
There is no subscribe form on a StatusOwl status page and no subscriber list in the dashboard. When you post an update, everyone currently looking at the page sees it within 30 seconds and everyone else sees it the next time they visit. No email, no SMS, no RSS feed.
The public API is live with per-key rate limiting and scopes, but it has two read-only routes today: list monitors and get monitor. There are no write endpoints, so incidents are declared in the dashboard or opened automatically by checks.
Give the incident somewhere to live.
Free forever on one page, with your own domain and automatic SSL. Unlimited incidents on every plan.