Skip to content

Coordinate when things go wrong

When a system goes down, the worst part is rarely the failure itself — it’s the chaos around it. Updates scatter across chat threads, email, and hallway conversations. Nobody has the same picture. The runbook is in a wiki someone has to go find. And once it’s over, the lessons evaporate before anyone writes them down.

This walkthrough shows how to run an incident from first alert to final postmortem in one shared place, with the AI working from the same context as your team. Everyone sees the same thread, the runbook and past incidents are right there, and the record writes itself as you go.

You’ll set up a reusable response workspace, run a live incident bridge, and turn the whole thing into a postmortem and an updated runbook — without screenshots, forward chains, or a single “can someone catch me up?”

Payments are failing. PagerDuty fires, and three people jump in from three time zones. Your on-call lead opens the incident bridge, pulls in the runbook, and asks Chat to summarize what’s outstanding. As the team works, updates land in one thread. When the API is healthy again, Chat drafts the postmortem, you export it as the official incident record, and you upload the corrected runbook so the next person on call inherits a better playbook.

Here’s how to set it up and run it.

Do this before you ever need it. The goal is a single, access-controlled home for incidents, with your reference material already linked.

A Folder is a workspace that groups conversations, a default assistant, and shared settings for a team. (You may see Folders called Projects.)

  1. Create a new Folder and name it something obvious, like IT Ops Response.
  2. Open the Members tab and add your responders. Give leads the Admin role and everyone else Member. Members can see and work in everything inside the Folder; Admins also manage who’s in it.

Now anyone you’ve added has the same access — no per-incident scramble to grant permissions.

→ See Plan and run projects for more on organizing work in Folders.

Section titled “2. Link a Collection of your reference material”

A Knowledge Collection is a set of documents the AI reads from and cites. Build one for incident response so every conversation in the Folder can draw on it.

  1. Create a Collection — call it Incident Response.
  2. Add your reference material:
    • Runbooks (the step-by-step recovery procedures)
    • Escalation contacts and on-call rotations
    • Past postmortems so the AI can spot repeat patterns
  3. Upload these as files. Chat supports PDF, Word, Excel, PowerPoint, CSV, TXT, Markdown, HTML, and more, up to 100 MB each. They’re scanned, then indexed so the AI can search and cite them.
  4. Share the Collection at Folder scope so every member of IT Ops Response can use it.

→ See Upload a file to add documents, and Internal knowledge base for more on Collections.

That’s the setup. It pays for itself the first time an alert fires.

3. Open a Shared Conversation as the bridge

Section titled “3. Open a Shared Conversation as the bridge”

When something breaks, start a new conversation inside the IT Ops Response Folder and share it with the responders. This becomes your incident bridge — one live thread everyone watches and writes to.

  1. Inside the Folder, start a new conversation. Name it for the incident, e.g. Payment API outage — 2026-06-13.
  2. Open Share and add the people responding. They’ll join the same thread in real time.
  3. Everyone sees the same messages as they arrive, and each person’s update is attributed to them — so you always know who said what.

Because the conversation lives in the Folder, it automatically draws on the Incident Response Collection. The runbook and past incidents are already in context.

→ See Share a conversation for sharing details.

4. Bring in the runbook and frame the situation

Section titled “4. Bring in the runbook and frame the situation”

Even though the Folder’s Collection is already linked, you can point the AI at the exact document for this failure.

  1. Post a short opening summary so everyone (and the AI) starts from the same facts:

    Payment API is returning 500s for ~30% of checkout requests, started 14:05 UTC. Error rate climbing. Confirming whether it’s the gateway or the upstream provider.

  2. Point the AI at the specific runbook for this service. Type # in the message box to open the document picker and pick the runbook from the Incident Response Collection — it attaches to your message as a chip. (You can also upload a fresh copy straight to the conversation.)

  3. Ask the AI to ground the response in the runbook:

    Based on the Payment API runbook, what are the first three diagnostic steps for an elevated 5xx rate, and who do we escalate to if it’s the upstream provider?

The reply cites the runbook directly, so you can click through to the source and trust the steps are current.

5. Track outstanding actions, owners, and blockers

Section titled “5. Track outstanding actions, owners, and blockers”

As the team investigates, updates pile up fast. Instead of scrolling, ask the AI to read the thread and give you the live state.

Useful prompts:

Summarize the current status: what’s been tried, what’s still outstanding, who owns each action, and any due dates.

List every unresolved blocker and who’s working on it.

Has anyone confirmed whether this is the gateway or the provider? Quote the message.

The AI reads the whole conversation and answers in seconds. Anyone who joins late can ask the same question and be caught up instantly — no recap meeting required.

6. Members add updates and the picture stays current

Section titled “6. Members add updates and the picture stays current”

This is the heart of the bridge. Responders post as they work:

Confirmed it’s the upstream provider — their status page shows a regional outage. Failing over to secondary region now. — owner: Priya, ETA 15 min.

Failover complete. Error rate dropping. Monitoring for 10 min before calling it. — owner: Priya.

Everyone sees each update live. When you re-run the status summary, the AI folds in the latest messages automatically. There’s no second tool to update and no risk of two people working from different versions of the truth.

→ See Summarize a document for more ways to ask the AI to distill long threads.

Once the incident is resolved, ask the AI to turn the entire thread into a structured postmortem. It has the full timeline, the actions, and the runbook in context.

Now that this is resolved, write a postmortem from this conversation. Cover: what happened, the timeline, the root cause, customer impact, what we did to recover, and concrete prevention steps. End with specific updates we should make to the Payment API runbook.

You’ll get a structured document: a clear narrative, a timeline, a stated cause, prevention actions with owners, and a list of suggested runbook fixes. Refine it in place if you need to:

Add a “detection” section — how long until we noticed, and how we can detect this faster next time.

Make the prevention steps a checklist with an owner for each.

8. Export it as the official incident record

Section titled “8. Export it as the official incident record”

When the postmortem reads right, export the conversation so you have a permanent, shareable record.

  1. Open the conversation menu and choose Export.
  2. Pick a format: PDF for a polished record to circulate, Markdown to drop into your wiki, or plain text / JSON for tooling.
  3. File it wherever incident records live — and share the exported document with stakeholders who weren’t in the bridge.

→ See Export for step-by-step export instructions and formats.

9. Update the runbook so the next incident is easier

Section titled “9. Update the runbook so the next incident is easier”

The postmortem named specific runbook gaps. Close the loop by feeding the corrections back in.

  1. Update your runbook document with the fixes the postmortem identified.
  2. Re-upload the corrected runbook to the Incident Response Collection (replace the old version).
  3. From now on, every conversation in the IT Ops Response Folder draws on the improved runbook.

Your reference material gets better with every incident, automatically — and the lessons live in the playbook, not in one person’s memory.

By the time the incident is closed, you have:

  • One shared bridge every responder watched live, with updates attributed to the right people.
  • A single source of truth for status, owners, and blockers — refreshed on demand, never out of sync.
  • A complete postmortem drafted from the real timeline, not pieced together afterward.
  • An exported incident record you can circulate and archive.
  • A better runbook for next time, already in place for the whole team.

The chaos of a scattered incident becomes one calm, well-documented response — and the next one starts from a stronger position.