Back to blog
2 min read
Status pagesIncidents

Incident timelines customers can follow (without a novel)

A good public timeline is a sequence of dated facts. Not a blog post, not a void: enough for someone refreshing on their phone.

NK

Nabin Khair

Founder

Status pages often have a timeline. Empty timelines feel abandoned. Novels feel like PR. Aim for a heartbeat of facts.

Anatomy of one entry

  • Timestamp with timezone
  • Phase: investigating / identified / monitoring / resolved (or your labels)
  • One or two sentences of new information

Example:

15:12 UTC — Investigating: elevated errors on API; some users cannot save. Next update by 15:40 UTC.

Rhythm

Match the promises in what to say during an outage. If you said thirty minutes, post at thirty minutes even to say "no change."

What never goes on the public timeline

  • Names of people who "caused" it
  • Unconfirmed blame of a vendor you have not verified
  • Jokes
  • Contradictions without correction ("all regions" then "only EU" with no note)

Correct earlier mistakes explicitly: "Update: impact is EU-only; earlier 'global' report was wrong."

Length

Five to twelve entries for a serious incident is common. If you are past twenty, you are narrating noise; batch updates.

After resolve

Final entry with end time and brief impact. Link a fuller postmortem later if you publish one. The timeline's job ended when customers could work again; the learning doc is a different artifact (postmortems).

Write like texts to a customer who is deciding whether to wait or call their own boss. That audience is the constraint.

Keep reading

More from the Tallwatch blog

More on monitoring, alerting, and status pages.