Updates and maintenance

An update is a short note you write by hand on a status page. It is the half of the page WireWatch does not derive for you: components tell a reader what is broken, and updates tell them what you are doing about it.

An update is not an incident. Incidents are opened and closed by detection and are internal; updates are written by a person and are public. Posting one does not touch an incident, and resolving an incident does not write one.

Posting an update is also the only thing that e-mails a page’s readers — what that sends, and what it never sends, is on subscribers.

The four states

Every update carries one of exactly four states, and they are the states a reader sees:

• investigating — you know something is wrong and do not yet know what.
• identified — you know the cause. Use this the moment you do, even if the fix is hours away.
• monitoring — the fix is out and you are watching to see whether it held.
• resolved — it is over.

They are a convention, not a workflow: nothing forces you through them in order, nothing stops you going back to investigating from monitoring, and posting one does not close anything. A page with no update at all is perfectly normal — it means nothing has needed saying.

What an update carries

• title — the one line a reader will actually read. Write it as a sentence, not a ticket number.
• body — the detail. Both are yours verbatim; nothing is templated or rewritten.
• status — one of the four above.
• at — the moment you posted it. Updates are shown newest first and the times are the reader’s main clue about whether anyone is still awake.

Scheduled maintenance

Any maintenance window that has not ended yet appears on the status page of its own accord, with its title and its start and end times. You do not post an update to announce one, and you do not have to remember to take it down: the window’s own end time removes it.

Which windows reach a given page follows the same scope rules maintenance uses everywhere else — that page is where they are written down, and they are not restated here. A window also puts the components it covers into a maintenance state rather than an alarming one, which is the same suppression the alerting side applies.

You published an update and the page has not changed

This is the single most reported non-bug in status pages, so it is worth stating plainly.

The public page does not read your live data. It reads a pre-composed snapshot.

A background pass — the refresher — runs on an interval. Each pass reads the current inputs of every published page through status_page_refresh_inputs(), works out each component’s status, and writes the finished public bytes through upsert_status_page_snapshot, which is the only thing that ever writes them. The public URL reads that stored result and nothing else. It never touches a monitor, an incident, a component or an update row, which is exactly why an unauthenticated request can be served at all.

So the page a reader loads is the page as of the last pass. Your edit is saved the moment you make it; it becomes public on the next pass. Reloading faster does not help, and neither does re-saving.

How long a pass is apart is configuration, not a promise this page can make — it is the refresher’s intervalMs setting, and a deployment is free to choose it. Ask whoever runs your WireWatch what it is set to rather than trusting a number written in a document. If you want to see your edit immediately, the editor’s own preview composes the same tree for one page on demand and is not gated on publishing, so a draft previews too.

The archive is a slower pass again

Older updates do not disappear when they scroll off. They are retained and reach the page as an archive, composed on its own cadence rather than on the status cadence — recomputing a long history for every page as often as a status changes would be a large and pointless load. That cadence has its own setting, DEFAULT_HISTORY_INTERVAL_MS, and it is deliberately much slower than the status one. An archive that has not been built yet is simply absent from the page; it is never a blank section.

When there is nothing wrong

A page whose components are all healthy is not an empty page. Each component reads operational and so does the page as a whole, the maintenance section is absent because no window is open, and any update from the last 30 days — including the resolved one that ended the last incident — is still there to read. A status page that says everything is fine is doing its job.

Recent updates means recent. An update older than 30 days leaves that section and is read in the archive instead; nothing is lost, and a page carrying no recent update at all simply shows no Recent updates section rather than an empty one. Age is the only thing that moves an update out, so the one you left investigating and forgot about stops sitting under an All systems operational banner once it is a month old.

A page with no components at all is different: it has nothing to derive a status from, so it reads no_data rather than operational. So does a component whose mapped monitors have all been paused or deleted. That state means “WireWatch is not watching anything here”, which is not the same claim as “this is up”, and the page does not make the second one on your behalf.