React Incident Timeline / Postmortem

The screen a review is run from. It keeps two things apart on purpose: a timeline of what happened, and a separate, honest list of why. The sequence and the causes are rarely the same events, and conflating them is how a postmortem turns into a blameless-sounding story that still teaches nothing.

SEV2resolved

EQ-07 etch chamber pressure excursion

Time to detect
0m
Time to acknowledge
6m
Time to resolve
1h 34m
  1. Etch tool EQ-07 chamber pressure alarm

    02:14

    Pressure exceeded 12 mTorr for 3 consecutive wafers.

    SPC monitor

  2. On-call process engineer acknowledged

    02:20

    M. Okafor

  3. Escalated to equipment engineering

    02:28

    Turbo pump current trending high; suspected bearing wear.

    M. Okafor

  4. Tool placed in maintenance, lots rerouted to EQ-09

    02:36

    8 lots rerouted; WIP impact contained to the affected chamber.

    Equipment eng.

  5. Turbo pump replaced, chamber pumped down

    03:12

    Field service

  6. Tool qualified and returned to production

    03:48

    Pressure stable at 8.2 mTorr across 5 qual wafers.

    Process eng.

Contributing factors

Trigger
  • Turbo pump bearing wore past its vibration limit mid-shift.
Contributing
  • Pump was 40 days past its recommended PM interval — deferred during the quarter-end push.
  • No redundant chamber for this recipe, so the whole tool went down.
Detection gap
  • Pump-current trend crossed its warning band 2 hours earlier but had no alert configured.

Installation

npx shadcn@latest add "https://kelvinui.com/registry/incident-timeline.json"

Props

PropTypeDescription
titlestringIncident summary
severity1 – 4Drives the SEV badge
statusIncidentStatusongoing, mitigated, or resolved
eventsIncidentEvent[]{ id, offset, at, kind, label, actor?, detail? }
factorsFactor[]{ id, category, label } grouped by cause type

Metrics are derived, not typed in

The three numbers a review argues about — time to detect, to acknowledge, to resolve — are computed from the events, not entered separately. Each IncidentEvent carries an offset in minutes from t0 (the earliest event) and a pre-formatted at string for display; the metrics read the first detect, ack, and resolve events and subtract. That means the header can never contradict the timeline below it, and adding an event that changes the story updates the numbers for free.

kind gives each event its icon and colour — detection is red, acknowledgement and escalation amber, mitigation the brand colour, resolution green — so the shape of the response is legible before a word is read. A long red-to-amber gap is a detection or paging problem; a long amber-to-green gap is a repair problem.

Causes get their own space

The factor list is grouped into trigger (the thing that broke), contributing (what made it worse or more likely), and detection gap (why it wasn't caught sooner) — the three questions a good postmortem answers. Deferred maintenance and a missing alert are not on the timeline because they are not events; they are the conditions that made the timeline inevitable, and they belong exactly here.

New components every week

Get the week's new Kelvin UI components and templates in one short email. No spam, unsubscribe anytime.