Incident Scribe Agent with Claude Code
A useful first update is assembled rather than written: the incident, its alerts, the closest past incident on that service, then five labelled sections in a fixed order and a matching note on the timeline. Claude Code gathers thoroughly before producing anything, which is what keeps the impact line honest instead of guessed. It also holds the hardest rule in this template, which is that it documents and never operates.
Watch it work before it's live
Run a staged conversation — no account needed. The agent handles it for real while a simulated world answers its tool calls; nothing touches real accounts, and nothing is actually sent.
P1: Checkout API error rate 11% for 6 minutes
TriggeredMonitor checkout-api 5xx ratio triggered at 14:02 UTC against a 2% threshold, currently 11.4%, with 340 of the last 2,980 requests returning 502 from the payments upstream. Two alerts merged into this incident, both from eu-west-1. Escalation policy Payments Primary, nobody has acknowledged yet.
Set up in minutes
Using this template drops you into a guided setup. It asks exactly this, nothing else:
Connect PagerDuty
One sign-in. The agent acts through your account, scoped to what this template uses.
Connect Slack
One sign-in. The agent acts through your account, scoped to what this template uses.
Runbook notes
What your team needs said about each service - what it does, who feels it when it breaks, and any standing context you want repeated in an update.
Comms style
How your incident updates should read and how often - the tone, who is reading, and the cadence that sets the next update time, for example every 30 minutes while a P1 is open.
Runs on Claude Code
Preselected for this page — connect your Claude Code account during setup, or switch to NoClick's built-in models with one click.
Watch it handle a test run
A staged conversation against a simulated world — then it’s live.
Why Claude Code for this agent
Gathers the whole picture
Alerts, alert counts and the closest previous incident are pulled before the update is composed, so the update contains something the channel did not already have.
Documents, never operates
Acknowledging, resolving and reassigning stay with the responder. A harness that follows a long instruction set to the end is what makes that line hold under pressure.
Before you fork
Will it post before anyone has looked at the incident?
Yes, and that is the intent, so the update is written from the alert payload and your runbook notes rather than from understanding. Impact the data does not confirm is written as not yet confirmed instead of estimated. The responder can correct it in the same channel, which is still faster than appointing a scribe.
Run it with a different agent
Put Incident Scribe Agent to work on Claude Code
Free to start. Guided setup, a test run against staged conversations, and it's live.