Start the incident response from the impact you can confirm

At 14:00, a customer asks why their report is still pending. By 14:03, a responder has checked that export and another from a different account. Both have passed the promised deadline. The API health check is green, and the cause is still unknown. Two people’s interrupted work is not.

Starting an incident gives that investigation a shared record and someone coordinating it. It does not certify a diagnosis or authorize every possible repair. It can help three capable people make three useful checks instead of unknowingly repeating one.

This tabletop uses Dispatch, a fictional report-export service. The output is an opening record and an internal update kept inside the exercise. No page, customer message or live-system change is part of the lesson.

The job number does not finish the customer’s work

Dispatch accepts a request, returns a job identifier, builds the report in a background worker and makes it downloadable. The identifier is a receipt for accepted work. The customer still needs the finished file, belonging to the right account and available to retrieve.

The following observations are supplied scenario facts. All times are UTC on the same fictional day:

The first impact statement can be precise without being large: at least two accepted exports from two accounts are overdue. We do not yet know the full population or when the problem began. The API check may be accurate; it is checking a different step.

Follow a delayed identifier through the worker toward download to find the unfinished step. That will focus the investigation. You do not have to finish the investigation before coordinating people around impact already verified.

Keep 14:00 as the arrival time of the report, not the start of the failure. The packet says nothing about earlier exports. A guessed onset written now can otherwise become an apparent fact in the later timeline.

Use the response rule the facts actually meet

This exercise’s rule is that multiple independently verified exports missing their deadline warrant coordination. The 14:03 finding meets it. Waiting for the deployment observation at 14:05 would postpone the response without improving what we know about impact.

A real organization supplies its own declaration and escalation rules, including safety, security and regulatory criteria. This packet has no numbered severity matrix, so calling the incident “SEV1” would invent one. State the impact and revise classification as scope becomes clearer. A small count can still involve a high-consequence operation.

If material impact continues and the local route is unclear, take the facts to the established on-call or escalation function. An ongoing interruption is a difficult time to invent the entire process.

Give the next responder a shared starting point

The opening record should give the next person enough to help: affected work, verified observations, unresolved scope, accepted roles and next checks. It does not need to reproduce the whole conversation.

Incident: Dispatch exports delayed
Status: Investigating
Known impact: Two verified accepted exports remain pending beyond
             the expected deadline, affecting two accounts.
Scope: Full affected population and regions are not yet established.
Timing: First report received 14:00 UTC; impact onset is unknown.
Coordination lead: Assign and confirm acceptance.
Technical lead: Assign and confirm acceptance.
Next checks: Compare export completion before and after 13:35 UTC;
             inspect pending-job age and worker results.
Cause: Unknown. Worker deployment is a hypothesis to investigate.
Next update: 14:15 UTC in the incident record.

The 14:15 update is a commitment to communicate, not an estimate of when repairs will finish. If the cause remains unknown, explain what was checked and what comes next. Waiting silently for a satisfying answer leaves everyone else unsure whether work is continuing.

The lead fields ask for acceptance deliberately. A name typed into a document does not show that its owner saw the request or took the role. One person can coordinate and investigate initially; separate the work when those demands begin competing.

Coordination still does not supply every production permission. The lead can organize a rollback proposal while the appropriate service owner checks compatibility and authorizes it. Beginning promptly and controlling consequential changes are compatible responsibilities.

Make the 14:06 update useful without guessing

At 14:06, use only the packet to tell the room what is known, what is being checked and when it will hear more:

We are investigating delayed Dispatch report exports. Two accepted jobs from separate accounts remain pending past the expected deadline; we are still checking the full scope. The API responds, but its health check does not test export completion. We are checking pending-job age, worker results and the 13:35 UTC deployment. The cause is unknown. We will update this record by 14:15 UTC.

The deployment is still a hypothesis, and 14:15 is still an update deadline. The message claims neither that all customers are affected nor that reports will be ready by then.

Keep the draft within the tabletop. Real customer communication requires the intended audience, appropriate detail and the organization’s communication policy. A useful update should not depend on a result the team has yet to obtain.

Join the response at 14:10

At 14:10, read the record as if you have just joined. Can you locate verified impact, unresolved scope, an accepted coordinator and the next check? If nobody has taken the lead, say so. The record should let a newcomer contribute without restarting the conversation.

Two shortcuts are tempting. “The API is healthy” does not resolve the delayed export. “The deployment caused it” turns a clue into an untested conclusion. Without those shortcuts, the next work is clearer: locate the delay and test explanations for it.

Save the opening record and update together. Dispatch has not been repaired by writing them. But people now have a shared starting point, and the next lesson divides investigation, action and communication so progress does not depend on one person’s attention.

Sources and example scope

Google’s incident-management guidance and the incident-response workbook support early coordination, clear responsibilities and a shared record. The site’s mitigation-authority guide separates coordination from production authorization; its MTTD guide keeps onset distinct from discovery. Dispatch, its response rule, timestamps and messages are constructed course material. No incident was declared or message sent in preparing the lesson.