Skip to content
Shakeride

Draft, not published · Updated

Writing an incident timeline your manager can read

An incident report has two readers: the engineers who will meet the same failure again, and the people who decide what to fund next. A clear timeline serves both, as long as it is written for someone who was not there.

Record while it happens

Reconstructing a timeline afterwards from chat history and memory costs hours and loses the order of events. Keep a running note with a timestamp on every line: what you saw, what you checked, what you changed.

A structure that works

Keep each part short; link to the details rather than pasting them.

  • Summary: one paragraph on what users saw, for how long, and whether it is resolved.
  • Timeline: detection, first response, key findings, the fix, the confirmation.
  • Cause: what failed and why it was possible, in plain language.
  • Actions: a short list, each with an owner and a date.

Write for someone who was not there

Spell out what each system does the first time you name it. Prefer what users experienced over internal identifiers. Leave out blame: the question is what made the mistake possible, not who made it.

All guides

Practise on a real failure

A live AWS account, already broken, and a clock. Fix it with the console and command line, then read a report of how you worked.