Incident Scribe Agent

In the first ten minutes of an incident the responder is debugging and everyone else is asking what is happening, and one of those two jobs always loses. This agent takes the second one: it reads the incident, its alerts and the closest past incident, posts one structured update to your comms channel, then writes the same thing back to the incident timeline. It never acknowledges, resolves or reassigns anything, so the responder keeps the incident and loses the audience.

What people use it for

• The first update in seconds - The comms channel gets what broke, who has it and when the next update lands before the responder has finished reading the alert. Nobody has to be appointed scribe at the start of a call.
• Stop the side channel questions - A stated next update time is what stops six people asking for status at once. Stakeholders wait for the clock instead of messaging whoever is in the middle of fixing it.
• Past incidents surface themselves - The closest previous incident on the same service, and how it ended, is pulled into the update. A repeat page arrives with its own history attached instead of being rediscovered at the postmortem.
• A timeline the postmortem can use - Every update is written back to the incident as a note with its time, so what PagerDuty records and what the channel was told stay the same story, minute by minute.

Before you fork

What do I need to connect before this works?

A PagerDuty credential that can read incidents and alerts and add notes, plus the Slack channel your incidents are communicated in. Your runbook notes and the cadence and tone you want go in as variables. It does not need permission to acknowledge or resolve anything, and it is safer if you never give it any.

What does it cost to run?

One run per incident event you forward, so cost follows your paging volume. Point the trigger at the services that need public communication rather than every service, and a normal week is a handful of runs. Noisy services are better filtered at PagerDuty than handled here.

Could it say something wrong while an incident is live?

It writes only from the incident, the alerts, the past incidents and your runbook notes. Impact the data does not confirm is written as not yet confirmed rather than estimated, and it states no cause, ETA or customer count it cannot see. It has no ability to acknowledge, resolve, reassign or escalate, so the worst case is an update thinner than you wanted, which the responder can correct in the same channel.