Ask Claude to Build an Incident Timeline from Git History and Logs
Postmortems are only useful if you know what actually happened. Instead of piecing together a timeline from memory and Slack messages, let Claude read the evidence and build it for you.
We had an outage between 2:00pm and 2:45pm today. Build a timeline from:
- Git commits merged to main in the last 24 hours
- Any config file changes in that period
- The deployment history (check CI/CD logs or deployment scripts)
Show what happened in chronological order.
Claude reads the git log, checks file modification times, and correlates the events into a clear timeline:
# Incident Timeline — 2025-03-28
14:02 — Commit abc123 merged: "Add Redis caching to user lookup"
14:05 — Deployment triggered (GitHub Actions workflow #892)
14:08 — Deployment completed to production
14:12 — First signs of impact (based on the error patterns in the code)
14:15 — The Redis config in .env.production is missing REDIS_CLUSTER_MODE
14:30 — Hotfix commit def456: "Add missing Redis cluster config"
14:38 — Hotfix deployed
14:45 — Service restored
Go deeper with specific questions:
# Find the root cause
Read the commit that was deployed at 2:05pm. Check if it introduced any
new environment variable requirements that weren't in .env.production.
# Check what changed
Show me every file that changed between the last stable deployment
and the deployment that caused the outage.
# Identify the blast radius
Which API endpoints call the UserLookup service that was affected?
How many users would have been impacted?
For the postmortem document itself:
Write a postmortem document based on this incident. Include:
- Summary (1 paragraph)
- Timeline (chronological)
- Root cause
- Impact (which endpoints, how many users)
- What went well
- What went poorly
- Action items to prevent recurrence
Claude reads the code changes, understands the architectural impact, and writes a document that goes beyond "a deployment broke things" to explain exactly what broke, why, and how to prevent it.
A good postmortem needs a good timeline — let Claude assemble it from the evidence instead of relying on anyone's memory of a stressful hour.
via Claude Code
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.