Incidents and maintenance

Automatic incidents

A monitor going down opens an incident on the page by itself, named after the monitor and carrying the error, and resolves it when the monitor recovers. Open incidents sit under the headline; resolved ones are listed at the foot of the page for 7 days. Posting an update on an automatic incident, or changing the monitors it names, makes it manual: it no longer resolves itself. Deleting the monitor resolves its automatic incident with a note.

Opening your own

The Incidents tab in the dashboard is where you open one: a title, a status (investigating, identified, monitoring), a first update, and the monitors or components it affects. Each monitor you tick gets a state: degraded, partial outage, major outage, or no change. Its row shows that state while the incident is open, unless its checks say worse, and goes back to its checks once the incident is resolved. The headline takes the worst of them, whatever the checks say: degraded reads as slow, partial as part of the page down, major as the whole page down. With no monitors ticked, the incident is about the whole page and you pick its impact instead, as you do when every ticked row is set to no change. If it started a while ago, set when; if it is already over, set when it ended too, and it goes straight into the page's history without telling anyone. The same can be done through the API or an agent.

Updates and resolving

Post updates as things change; each one carries the status at that moment. Setting the status to resolved closes the incident. Every update has a Tell subscribers box, ticked; untick it and the update is posted on the page without a mail. An update already posted can be corrected from its Edit link, and nobody is told about the fix. The title, states and affected monitors can be edited without posting, and once it is resolved a post-mortem can be written; it shows under the incident on the page. Pointing at a bar on a strip names the incidents that touched it, and its drawer links to them.

Incident pages and history

Every incident and maintenance window has a page of its own at /incidents/<id> under the status page, with its updates and post-mortem. Its title on the page links there, and so does its entry in the feeds. Older incidents are at /history, by month, as far back as the plan keeps history and never less than 30 days: 30 days on Free, 90 on Hobby, a year on Pro. A locked page asks for its password on these too.

Drafts

On Pro the update box and the post-mortem box have a Draft from the checks button. It writes the text from what was recorded: which monitors failed, from when to when, with which errors, from which locations, the response times before and during, deploy markers in the two hours before, and the updates already posted. The checks do not know the cause, so the draft leaves a bracketed gap for it. The text lands in the box; nothing is posted until you press the button you would have pressed anyway. Twenty drafts a day per account. The facts are sent through OpenRouter to a language model to be written up, only to providers that keep nothing and train on nothing; URLs go without their query string or login, tokens and keys in errors, deploy notes and updates are left out, and request headers and bodies are never sent.

Under the box the draft says when it was written and from how many monitors, failed runs, deploys and updates, and What it was given shows the facts exactly as sent. When the drafting service cannot be reached, a plain draft from the incident's own times stands in, says so, and does not count toward the twenty.

Maintenance windows

A maintenance window is planned with a start and an end, entered in your own time zone. While it runs, checks on the affected monitors (or the whole page) are kept but not counted, no alert goes out, their rows say Under maintenance, and the page says maintenance is in progress. It ends by itself when the clock says so, with a final update on the page, or earlier from the dashboard. A window can last up to seven days.

A window can repeat every week on the same day, every month on the same date, or every month on the same weekday (the second Tuesday, the last Friday). Its time stays the same in the time zone it was planned in, through daylight saving; a monthly date the month does not have falls on its last day. Each window after the first goes on the page a week before it starts, as its own entry that can be edited or deleted alone, and subscribers hear about it as they would about one planned by hand. Stop repeating, on any of them, plans no more; the ones already planned stay.

/maintenance.ics next to the page is its maintenance as a calendar: the last 30 days, what is planned, and what repeats in the next 90 days. Get updates on the page links to it for calendar apps; in Google Calendar, add it under Other calendars, From URL.

Templates

Under Incidents, Templates: a saved title, status, impact, first update and set of monitors, for incidents or for maintenance. Picking one at the top of the incident form fills it in; everything can still be changed before posting.

What subscribers hear

Every update you post goes to the page's subscribers unless you untick Tell subscribers, and so does an automatic incident once the outage has lasted longer than the page's threshold (Subscribers tab; set it to Never and only what you post reaches them). For maintenance they hear when it is planned, with its start and end, a day and an hour before it starts as the window's reminders say (an hour by default; each goes only when the window was planned more than an hour further ahead than it), and when it ends, unless Tell subscribers was unticked when it was planned. Subscribers who chose monitors only hear about incidents naming those, and about incidents on the whole page. The subscribers page has the rest.