Incident Update Agent

Goal

When an alert fires, assemble a short internal brief and a customer update from facts on-call pastes — impact, what you have checked, the next check — without the model inventing a root cause.

Tools required

Direct is the vendor's public site. Affiliate appears only when ShipPlays is enrolled in that program.

• Sentry

  Direct

  Or the alert page you already open. You paste links and symptoms. You do not paste secrets or customer payloads.

• Notion

  Direct

  The incident doc with blanks. A markdown file in the repo is better if that is where your runbooks live.

• The status channel you already use

  Direct

  A human posts. The model does not get the status-page password.

Step-by-step setup

1. Turn your last good write-up into blanks

   Start time, customer impact, systems you believe are involved, what you have checked, what you will check next, what you are explicitly not claiming, owner, next update time. Empty blanks stay empty. Unknown is allowed.

2. Freeze four status words

   Investigating, identified, monitoring, resolved. The model may not invent a fifth. Identified requires a human to have filled the known-cause blank. Otherwise the word is investigating.

3. Run it on a game day before you trust it at night

   Fake an alert. Fill only the facts you would actually have in the first 10 minutes. If the draft sounds like it knows the cause, the template is leaking leading language. Fix the template, not the prose at 02:00.

4. Internal brief first, customer update second

   The customer update may only use facts present in the internal brief. It leads with impact and the next update time. It does not apologize in three paragraphs. It does not guess all customers or no customers.

5. A human posts, on a clock

   Pick a cadence before the incident, for example every 30 minutes while customers are affected, even if the update is we are still confirming scope. For a severe incident, a second human reads the public line if someone else is awake. The agent does not restart services, roll back, or change DNS.

6. The next morning, a skeleton, not a verdict

   The timeline prompt drafts a postmortem skeleton from the doc: timeline, what detected it, what was confusing, what to change. You add action items and owners. The model does not assign people and does not name a human as the cause.

Exact prompts

Write an internal incident brief from these blanks only. Do not invent a root cause, a scope, or a customer impact. If a blank is empty, write Unknown.

Status words you may use: investigating, identified, monitoring, resolved.
You may use "identified" only if Known cause is filled. Otherwise use investigating.

Blanks:
- Start time: {START}
- Impact: {IMPACT}
- Systems we believe are involved: {SYSTEMS}
- Checked: {CHECKED}
- Next check: {NEXT_CHECK}
- Known cause (optional): {CAUSE_OR_EMPTY}
- Not claiming: {NOT_CLAIMING}
- Owner: {OWNER}
- Next update time: {NEXT_UPDATE}

Return the brief in those same headings, plus a one-line status. Do not add a theory section. Do not recommend a restart, rollback, or DNS change.

Write a customer-facing update using only the internal brief below. A human will post it.

Internal brief:
{BRIEF}

Rules:
- First sentence: what customers might notice, or say we are still confirming who is affected.
- Second: what we are doing now, from Checked and Next check.
- Include the next update time.
- Do not state a root cause unless the brief's Known cause is filled. If it is filled, one sentence, no blame.
- Do not apologize more than once, and only if impact is more than Unknown.
- Do not name customers, internal hostnames, or people.
- No humor. No "blip." Under 120 words.

Return the update and a list of any phrase you considered that was not in the brief.

Draft a postmortem skeleton from this incident doc. Do not assign owners. Do not name a person as the cause. Do not add a root cause that the doc does not state.

Doc:
{INCIDENT_DOC}

Return:
- Timeline, times only from the doc
- How we detected it
- What was confusing in the first updates
- What held (checks that helped)
- Changes to consider, as questions, not tickets
- Facts still missing

If the doc never stated a cause, the cause line is "not established in this doc."

Expected results

• A first customer update that is small and honest.
• A cadence instead of silence followed by a long explanation.
• A skeleton the next morning, before folklore sets in.
• Language support can repeat without translating.

Guardrails

• No root cause in customer copy unless a human wrote it in the known-cause blank.
• No customer names, payload samples, tokens, or secrets in the prompt.
• The agent does not restart, roll back, or change DNS. Those stay in the runbook, done by on-call.
• If impact is unknown, say you are still confirming who is affected.
• Do not publish a write-up that names a person as the cause.

Common mistakes

Related

• Release Notes Pipeline
• Outbound Account Research Sprint