reph

Templates · Engineering

Incident status update template

Stakeholder and customer communication during an active incident: current status, impact, what we know, next update time and a running update log

Start with this template →Sign in

Opens on reph with the template ready to start. No account needed; sign in to keep your document.

Use it when

An incident is in progress and customers, support or leadership need regular, plain-language updates on a predictable cadence

Who it's for

SREEngineerEngineering managerCommunicationsCustomer success

Part of a kit

Incident response, step 3 of 4. Runbooks and on-call handoffs before, status updates while it burns, a blameless postmortem after.

Filled example

The template filled in for a made-up company, so you can see what good looks like.

Incident: Delayed payment confirmations

Incident commander: Marco Ruiz · Date: 2026-09-22 · Started: 14:05 UTC · Comms lead: Hana Sato

Status Severity Next update
Monitoring SEV-2 16:30 UTC
Mermaid diagram (drawn as a picture in reph)
flowchart LR
  A[Investigating 14:12] --> B[Identified 14:48]
  B --> C[Monitoring 15:35]
  C --> D[Resolved]
  C -. regression .-> B

Current status

Payments made in Fernhill Pay are going through, and confirmations are arriving again. Some confirmations sent between 14:05 and 15:30 UTC arrived late; we are watching closely before we call this resolved.

Impact

  • Affected: Merchants in the EU region. About 11% of payments between 14:05 and 15:30 UTC showed as "Pending" for up to 40 minutes before confirming.
  • Not affected: No payments were lost or charged twice. US and APAC merchants were not affected.
  • Workaround: None needed now. Merchants who refunded a "Pending" payment during the window should check the payment list; support can reverse duplicate refunds.

What we know

  • A configuration change at 14:02 UTC reduced the capacity of the service that sends confirmations in the EU region.
  • Rolling back the change at 15:31 UTC restored normal confirmation times (under 3 seconds).
  • We are still confirming that every delayed confirmation has been delivered; so far 41,200 of 41,350 have.

What we are doing

  • Replaying the remaining 150 confirmations, expected to finish by 16:15 UTC.
  • Holding further configuration changes in the EU region until the review is complete.

Next update

Next update by 16:30 UTC.

Update log

Time (UTC) Status Update
15:40 Monitoring A fix is in place and confirmations are arriving normally. We are delivering confirmations delayed earlier today.
15:05 Identified We have found a configuration change that caused delays and are rolling it back.
14:35 Investigating Confirmations for some EU payments are delayed. Payments are not lost or duplicated.
14:12 Investigating We are investigating reports of payments stuck in "Pending" for EU merchants.
Internal notes (do not publish)

Incident channel: #inc-2026-09-22-eu-confirmations. Dashboard: Payments EU latency. Config change: CHG-4471. Postmortem owner: Marco Ruiz, draft due September 26.

The template

Show the blank template

Incident status update

Incident commander: [your name] · Date: [date] · Started: [time, UTC] · Comms lead: [name]

Status Severity Next update
Investigating / Identified / Monitoring / Resolved SEV-? [time, UTC]
Mermaid diagram (drawn as a picture in reph)
flowchart LR
  A[Investigating] --> B[Identified]
  B --> C[Monitoring]
  C --> D[Resolved]
  C -. regression .-> B

Current status

One or two sentences a customer can read on a phone. Lead with what they experience, not with what broke internally.

Impact

Who is affected, what does not work, and since when. Numbers beat adjectives: "about 8% of checkout attempts fail" not "some users see errors".

  • Affected:
  • Not affected:
  • Workaround:

What we know

Confirmed facts only. Say plainly what you are still investigating.

What we are doing

The current mitigation and what comes next.

Next update

A specific time, and keep the promise even if the update is "no change".

Next update by [time, UTC].

Update log

Newest first. Each row is what was published, word for word or close to it.

Time (UTC) Status Update
Investigating We are investigating reports of [symptom]
Internal notes (do not publish)

Links to the incident channel, dashboards and the postmortem once it exists.

Questions

How often should we update?
Every 30 minutes while investigating, hourly once monitoring, and always at the time you promised even if nothing changed
Should we name the root cause?
Only once it is confirmed; say what you know and what you are still checking, and leave the why for the postmortem
Who publishes it?
The communications lead posts it after the incident commander confirms the facts

Fill it with your agent

Connect Claude to reph over MCP, then paste this. The draft arrives as suggestions you accept or reject section by section. How to connect Claude.

Find my reph doc "Incident status update" with search_docs, then read it with read_doc. Draft the latest update from the incident channel, on-call timeline and alerting dashboard: status, who is affected, what we know and are doing, in plain language with no jargon or blame, plus a new update log row. File it with suggest_edit, one replace_section op per section (heading line kept) so each can be accepted alone. Ask each open question (impact numbers, next update time) with add_comment quoting that section's heading line, then call request_review with a one-line summary.

Related templates

Runbook

Operate a service: dashboards, alerts, and step-by-step procedures

EngineerSRE

On-call handoff

What the next on-call needs to know

EngineerSRE

Incident postmortem

Blameless review: timeline, impact, root cause, action items

EngineerSREEngineering manager

ADR

Architecture decision record: one decision, its context and consequences

EngineerTech leadEngineering manager

Agent instructions

The charter your AI coding agents work from, project overview through review checklist

EngineerTech leadEngineering managerSRE

AI feature eval plan

How you will measure an AI feature before and after launch: the task, a quality rubric, the eval dataset, metrics, baseline vs target, human review, regression gates and a cost and latency budget

EngineerTech leadProduct managerResearcher

Start with this template →Sign in