UptimeHunt Docs
Status Pages

Publish incident updates

Post a public incident timeline your visitors can follow, keep an internal-only conversation alongside it, and know exactly what does — and never does — reach your public page.

Publish incident updates

A status page's incident timeline is entirely manual — nothing your alert engine detects becomes public on its own. You decide what to publish, and when, from a title, an impact level, and the affected components.

Start a public incident

  • From an internal incident — open the incident's detail page and click Publish to status page…. Pick which status page to publish to, and the composer prefills a first update from the incident's own summary and pre-selects the components whose monitor backs this incident. Edit anything before posting.
  • From the status page itself — go to the page's Incidents tab and start one directly, for anything you want to communicate that didn't come from an automated detection (or shouldn't be tied to one).

The unified timeline

Every public incident shows one chronological timeline, oldest to newest, mixing two kinds of entries:

  • Public updates — the status ladder (investigating → identified → monitoring → resolved) plus a markdown body. This is what visitors see, in the order you posted it.
  • Internal notes — team-only commentary: what you're actually seeing, who got paged, what the real root cause turned out to be before you're ready to say so publicly. Each entry shows the author's avatar, name, and timestamp; internal entries carry an amber Internal badge so they're never mistaken for something public.

Internal notes never appear on your public page

Notes posted on the Internal side of the timeline exist only in the management UI. They are never included in the snapshot, the public page, the badge, the feed, or incident search — the public and internal lanes are structurally separate all the way down, not just hidden by the UI. Use notes freely for the honest, unfiltered version of what's happening.

Posting an update

A composer sits at the foot of the timeline and toggles between two modes:

  • Public update — pick the new rung on the status ladder and write the body. Posting a resolved update is what resolves the incident; there's no separate "close" action.
  • Internal note — just a body, no status change, visible only to your team.

You can edit an update's text after posting, but not its status step or author. An update can be deleted as long as it isn't the incident's last one — a public incident always keeps at least one update; deleting the resolved update reopens the incident, recomputed from whatever's left on the ladder. Internal notes can be edited or deleted by whoever wrote them.

Once an incident is resolved, the composer collapses to a quiet "Post follow-up…" — useful for a postmortem link or a note that it recurred — without reopening the ladder on its own.

Searching incidents

The Incidents tab's search box matches incident titles and public update bodies only — never internal note text. It's a public-content search, not an audit tool for your team's private discussion.

On this page