Build an incident timeline
Builds a timestamped incident timeline from chat logs, alerts and deploy records, marking detection, escalation, mitigation and the gaps between them. Use when preparing a postmortem.
A postmortem is only as good as its timeline. Raw material comes from tools that log in different timezones and formats, chat messages are posted minutes after the events they describe, and the most useful facts are the gaps: twenty minutes between the first customer report and the first alert, or an alert that fired and sat unacknowledged. The timeline must be exact, sourced and blameless.
Build an incident timeline in from this material:
- Parse every timestamp. Convert each to , noting the source timezone when it differs. If a source has no timezone and you cannot infer it from context, say so and mark those times "unverified zone".
- Extract events and tag each with one type: trigger, impact-start, detection, acknowledgement, escalation, decision, mitigation-attempt, mitigation-effective, communication, resolution, other.
- Mark each event "recorded" (the source states it) or "inferred" (you deduced it), and give the source for every event.
- Compute the key intervals: impact start to detection, detection to acknowledgement, acknowledgement to mitigation, impact start to resolution. If a boundary event is missing, say which and do not compute that interval.
- Find gaps: any stretch of more than 15 minutes during impact with no recorded action, detection by a customer or a person before any alert, alerts that fired without acknowledgement, communication cadence breaks, failed mitigation attempts.
- List conflicts where sources disagree, with both values.
- Do not invent events or fill gaps with plausible guesses. A gap is a finding.
- Do not infer causality. "Deploy at 10:02, errors from 10:05" is two events, not a cause.
- Stay blameless: describe actions and systems, use the role or handle exactly as given, and add no judgement words such as "failed to" or "should have".
- Quote source text only when the exact words matter, and keep quotes short.
Key metrics
A table: interval, start event, end event, duration.
Timeline
A table in chronological order: time (), event, type, recorded or inferred, source.
Gaps
Numbered, each with its time range and why it matters for the postmortem.
Conflicts
Bullets, or "None".
Missing data
What to pull from which system to complete the timeline.
1 required value still a placeholder; the assistant will ask for it.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Software engineering
- category
- Incident and operations
- level
- Intermediate
- made for
- Site reliability engineer, DevOps / platform engineer, Engineering manager
- risk
- read-only
- version
- v1.0.0 · incubating
- reviewed
- 2026-10-02
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai
use in
npx @hermes-hq/hodios install build-incident-timeline --target claude-codenpx skills add hermes-hq/hodios-dist --skill build-incident-timeline -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-software-engineering@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of Incident and operationsIncident commander
Runs a live incident like an experienced incident commander, assigning roles, keeping a steady comms cadence and driving mitigation before root cause. Use as the coordinating voice during an outage.
incident-commanderInstrument a service for observability
Plans and adds logs, metrics and traces using OpenTelemetry conventions, golden signals, useful log fields, cardinality limits and first dashboards. Use when a service is hard to debug in production.
instrument-service-observabilityPlan a game day or chaos exercise
Plans a game day or chaos exercise with failure scenarios, hypotheses, blast-radius limits, abort criteria, roles, an observation checklist and a follow-up review. Use to test resilience.
plan-game-dayTriage a production alert
Turns a firing production alert into a severity call, the safest mitigation to try first, ranked hypotheses and the next checks. Use in the first minutes of an incident or page.
triage-production-alertWrite an incident status update
Writes a clear status update for an ongoing incident, tuned to customers, internal teams or executives, without speculation or promises the team cannot keep. Use for status pages, Slack and email.
write-incident-updateWrite a blameless postmortem
Turns incident notes, chat logs and timelines into a blameless postmortem with impact, timeline, contributing factors and owned action items. Use after an incident is resolved.
write-postmortem