Telling your customers what is happening, and what happened
Incidents & maintenance
Monitors say whether something answers. An incident is what you write about it: the entry your customers read, subscribers are told about, and a procurement team scrolls through a year later.
Dashboard → Incidents. The list shows what is live and what is posted, with a filter for each state, and the two buttons that start everything: Post incident and Schedule maintenance.
Key features
- Write in one language; the others are filled in for you and stay editable.
- Updates with a status (Investigating, Identified, Monitoring, Resolved) that build a timeline.
- Templates for the incidents you post more than once.
- Scheduled maintenance with reminders; it starts, completes and overruns on its own.
- Postmortems in Markdown, published under the incident.
- Automatic incidents from monitors that stay down, behind two gates.
Posting an incident
Post incident opens a dialog with three tabs. These are its fields:
What happened
A title and a summary, in your default language. Keep the summary about impact rather than cause. “Checkout is returning errors for some customers” is what somebody needs at that moment; the database failover that caused it belongs in a later update.
Scope & timing
The type (an incident, or maintenance), the services it affects, and when it started. Attaching services is what marks them as impacted on your page and lets people filter the feed by them. A resolved time appears when you are posting something that is already over.
Translations
If your page publishes in more than one language, the translation is written for you when you publish. You can open this tab afterwards to read it and change any phrase; your edit is kept. See Languages.
Starting from a template
At the top of the dialog you can pick a template. Applying one fills the fields; it publishes nothing, and you still review every field before you submit. Templates live in Dashboard → Incidents → Templates: five ready-made ones, and up to fifty of your own, each with a title, summary and default services, per language.
Updates and statuses
An incident is a thread, not a single note. Each update you post carries a status, is timestamped, appears under the incident on your page, and goes out to subscribers.
| Status | Say it when |
|---|---|
| Investigating | You know something is wrong and not yet what. |
| Identified | You know the cause and are working on it. |
| Monitoring | A fix is in place and you are watching it hold. |
| Resolved | It is over. This closes the incident. |
Updates are append-only: a published update is part of the record and cannot be edited or removed. The rhythm that works is an update when something changes and an update when nothing has changed for a while; silence during an outage reads as nobody being on it.
Publishing silently
Every update has a checkbox: Publish silently, no subscriber email or webhook. Use it for a correction, a translation fix, or the fourth update in ten minutes. The timeline marks each update as Published silently or Notifications requested, so you can always see which ones went out.
Editing
The pencil on an incident opens the same three tabs, for the title, summary, services and times. Editing does not notify anyone unless you tick Email subscribers in that dialog.
Resolving
Posting a Resolved update sets the end time, returns the affected services to normal on your page, and sends a final notification. Resolved incidents stay in the ledger permanently; that history is most of what makes a status page worth having.
Postmortems
A resolved incident gets a Write postmortem button. The postmortem is Markdown, written per language, with Save draft and Publish. Nothing is visible until you publish; the first publication tells subscribers, and later edits do not. Published postmortems appear under the incident on your page at their own address.
Scheduled maintenance
Schedule maintenance opens its own dialog: an announcement, the services and timing, and translations.
| Field | What it does |
|---|---|
| Start | When the window opens. It appears on your page as planned work from the moment you publish. |
| Planned end | When you expect to be done. |
| Subscriber reminder | Off, or 1 hour, 6 hours, 24 hours, 48 hours or 7 days before the start. Subscribers are told when you publish and again at the reminder. |
A window moves through its states on its own: scheduled, then in progress when it starts, then completed when the planned end arrives if the affected services are healthy. If they are not, it becomes overrun and stays open until you finish it, so a window never quietly closes on a service that is still down. Complete now ends it early; Cancel maintenance withdraws it.
Checks during the window are left out of uptime and response-time figures. If you also want visitors to your actual site to see a branded page during the window rather than a browser error, see Outage page.
Incidents this product opens for you
When a monitor stays down, an incident can be opened on your page automatically, with a title and body in every language you publish. It is off by default and switched on per monitor. Two deliberate gates sit in front of it:
- Two consecutive failed checks before the monitor is considered down at all. This is the bar for alerting your own team.
- Fifteen continuous minutes down before anything is published to your customers. A blip that clears on the third check is not worth a permanent entry in your ledger, mailed to every subscriber, in every language.
When the service recovers, that incident is resolved automatically too. Edit it and it becomes yours: we stop touching it. Nothing is opened during a maintenance window, or on top of an incident you have already written.
One more guard, worth knowing about because it looks like a bug otherwise: if a large share of all monitors being checked fail in the same moment, that is treated as evidence the check path itself broke rather than the whole internet. Your team is still alerted; publishing to public pages is withheld.
Doing this from your own systems
The public API lets a deploy pipeline or an internal alert create an incident, edit it, append timeline updates and resolve it. The account needs the Write API capability. See the Incident API reference for the supported fields.
Use the dashboard for templates, postmortem publication, and maintenance settings such as planned end times and reminders. Those workflows are not exposed by the public Incident API.