1. Pick a status honestly, not diplomatically
Every incident update carries one of four statuses: investigating, identified, monitoring, or resolved. There is no in-between wording to soften a status into, on purpose: the dashboard's own update form only offers those four, so the question during a bad hour is never how to phrase it, only which of the four is true right now.
2. Start from a template or a live alert, not a blank box
The incident-create form lets you pick a saved template, which expands its title and body against two real placeholders, the affected component's own display name and the current time, never free-typed guesses. Better still, if a monitor is already failing with no incident open, the form lists it as a one-click starting point: picking it prefills the component, the region, and the time the region actually flipped from the probe's own record, not from memory.
3. Say which region, not just which component
The region field only ever offers the regions that monitor is actually probed from, so an incident can never claim a region it was never checking. State it in the update body too: "degraded in Frankfurt, healthy elsewhere" tells a subscriber something a single global status can't, and it matches what the public status page is already showing region by region.
4. Acknowledge it, then use notes for anything that isn't customer-facing
Acknowledging an incident timestamps who is on it, and any teammate can add their own acknowledgment alongside others already there, interleaved on the incident's unified timeline next to the probe transitions and status updates that opened it. Notes on that same timeline are for the team only: plain text, never rendered on the public status page, for the context worth keeping (a hunch, a linked deploy, who's paging the vendor) that has no place in a subscriber-facing update.
5. Don't resolve until the probes agree, or say plainly why you did
Posting Resolved while our own probes still read that component down or degraded stops and asks first: it names the last probe reading and requires an explicit confirm before publishing, because Resolved tells every subscriber and every visitor the outage is over. If the fix genuinely landed ahead of the next probe round, confirm and move on; otherwise post a monitoring update and let the next reading resolve it for you.
6. Why measured components beat hand-flipped checkmarks
A status page updated by hand, during the incident, by the people busiest with the incident, drifts toward green under an incentive nobody has to be dishonest to feel. That's the case realuptime.io/blog/status-pages-that-cannot-lie makes for building the lie out structurally rather than merely discouraging it. realuptime.io/blog/chatgpt-outage-green-checkmarks is the concrete version: a real outage where a manually maintained component board stayed green through it, measured from four independent regions against the same claim. Templated updates fed by measured state, not a person deciding how much to admit, is the whole difference.
Go deeper
The full reference lives in the docs: Status pages documentation. Error codes named above are each explained in the error-code reference.