Aftermath
Overview
Aftermath is an incident memory product for engineering teams that do not have a dedicated SRE. It is a separate company and codebase from internal post-incident platform work I did at enterprise scale: same problem space, but built for teams that need the memory layer without a dedicated platform org. It captures what happens during an incident, turns the record into a post-mortem draft, and keeps the result searchable for engineers and AI coding agents.
Aftermath
Incident capture, post-mortem drafts, and searchable history for lean engineering teams.
The Problem
Small teams still have real incidents, but the tooling around them is usually built for larger organizations. The response happens in Slack, a few links get pasted into a thread, someone rolls back a deploy, and the post-mortem is written later from memory.
That is enough to recover once. It is not enough to build a useful record. The next engineer or coding agent trying to understand a similar failure has to reconstruct the same context again.
The betIf incident context is captured while the team is already responding, the post-incident record can become a durable asset instead of a cleanup chore.
What I Built
- Cues that open an incident from a manual report, webhook, Sentry alert, or PagerDuty event
- Live Stage, a real-time incident page for severity, affected services, links, Slack context, and timeline events
- Encore, an AI-drafted post-mortem with summary, impact, root cause, resolution, lessons, and follow-ups
- Playback, a searchable incident memory that keeps published post-mortems useful after the incident closes
- Agent access for checking related incidents before a PR, finding a similar past outage, or drafting a runbook from history
The Tradeoff
The product has to avoid becoming another incident response system. PagerDuty, incident.io, Rootly, Slack, and observability tools already own parts of that workflow. Aftermath works best when it sits beside them: collecting useful signal, structuring the record, and making past incidents easy to reuse.
That constraint shaped the build. I kept the core loop narrow: open an incident, capture the timeline, draft the post-mortem, publish it into Playback, and expose that memory to people and agents. The deeper technical pieces stay behind the scenes so the showcase can stay focused on the product shape.
Where It's Going
Aftermath is still early. The current build covers the full lifecycle, from Cue through Live Stage, Encore, and Playback, plus Slack capture, GitHub and alerting monitors, Situation Rooms, and agent access over MCP. I am dogfooding the loop on my own projects and running research calls with lean teams while early access is open on aftermath.sh.
The next useful milestone is not more surface area. It is proving the loop with real incidents from teams outside my own stack.
Positioning
Memory layer
Read-only layer beside PagerDuty, Sentry, Slack, and incident.io
Stage
Early access
Full lifecycle built; early access waitlist open
Target team
2–20 engineers
Engineering teams without a dedicated SRE or platform org
statusBuilding now. If your team runs lean and keeps losing incident context after recovery, I would like to compare notes.
Book an Aftermath research call
If incident follow-up, post-mortems, or repeated outages are painful on your team, I would like to learn how you handle them today.
- Incident response
- Developer tools
