Build a shared picture of an incident

At 14:10, four things seem to be pointing in the same direction: a missing report, a falling completion chart, an earlier deployment and a storage timeout. It would be easy to turn them into one confident story. The useful work is to find out which links in that story are supported.

Continue the fictional Dispatch tabletop with one shared document. All times below are UTC on the same illustrative day. You will turn several partial observations into a current picture that another responder can use, while keeping the questions open enough for new evidence to change the answer.

Evidence	Event time	Time learned	What it establishes
Customer says an export submitted at 14:01 is still missing.	14:01 submission	14:07	One reported delayed operation.
Completion rate falls in a five-minute chart bucket.	Bucket ending 14:05	14:08	A population-level change somewhere in that bucket.
Worker deployment completes.	13:35	14:09	A change preceded discovery of impact.
Storage timeout appears in one worker log.	14:04	14:10	One observed dependency error.

Separate observations from interpretations

Give the shared document three kinds of statement: what was observed, what might explain it and what remains to be found. “The deployment caused the incident” is an explanation under test. “Storage timed out once” is an observation. Neither becomes stronger because the two sit near each other in the chat transcript. Keeping them distinct leaves the investigation room to change its mind.

Record event time and discovery time separately. The customer report arrived at 14:07, but the submitted job began at 14:01. Neither time proves when the wider service first became affected. A bucket ending 14:05 cannot justify an exact onset timestamp without finer evidence.

A chart bucket combines observations over an interval. If completions fell between 14:00 and 14:05, the chart may reveal the drop only when that bucket is displayed. It cannot tell you that the service broke at precisely 14:05. Likewise, a customer who reports a missing export at 14:07 is telling you when the team learned about that job, not when every affected job first began waiting.

Keep those distinctions visible in the document. A useful entry reads: “At 14:07 we learned that an export submitted at 14:01 was still missing.” It contains two clocks and no invented outage start. The next responder can now compare that job with earlier completions instead of building an investigation on false precision.

Make the next question useful

Ask whether delayed exports occur on both old and new worker versions, and whether the timeout rate changed for the same region and interval. Those checks can distinguish the release hypothesis from a shared dependency failure. Assign an owner and a check-in time rather than sending the entire team to inspect everything.

Coordination establishes shared priorities; it does not grant permission for every production change. Keep a separate action column with proposed action, required authority, approval and observed result. That prevents a suggested rollback from being mistaken for a completed one.

Reconcile new evidence without rewriting history

Inject this new fact: at 14:13, a responder finds delayed exports on the old worker version too. Update the working hypothesis and the next check. Preserve the original deployment hypothesis and why it weakened; the record should explain the team's decisions using what was known then.

Now write a three-sentence status: affected operation and scope, current investigative progress, and next update time. A suitable response says exports are delayed, both worker versions appear affected, and storage behavior is being compared. It should not claim the deployment is cleared of all involvement merely because the simplest version-specific theory weakened.

The old-version delays complicate the neat story. Rolling back the new worker would not explain why an old worker is also waiting, so the shared storage dependency deserves attention. The deployment might still have increased load on that dependency. Keep that possibility and compare the workload. A useful shared picture gets more precise when a theory weakens; it does not need to declare a suspect innocent.

Write the current view as a short, revisable explanation: “Exports are delayed on both worker versions. We are checking whether storage waits account for the delay. The deployment preceded the reports, but its contribution is not established.” That is enough direction to divide the investigation without making the conclusion part of the assignment.

Check the finished record

Another responder should be able to identify current impact, evidence quality, leading explanations, active owners and the next decision. If the document contains a long chat transcript but none of those answers, summarize it into a usable current view while retaining links to source observations.

The tabletop cannot establish a real root cause. It can leave the next responder with something better than the confident story available at 14:10: a current account of impact, the evidence behind each explanation and the people pursuing the next questions. That is enough structure to move together while the cause is still being worked out.

Sources

Google's incident-response chapter describes coordinated response. The evidence packet and times above are synthetic.