MobSessiondocs

Mob an incident

Put multiple responders on one live investigation, steering a single shared agent that reads logs, traces the bug, and proposes a fix while everyone watches.

During an incident, the on-call engineer starts a MobSession in the affected repo, shares the link, and responders join from anywhere to steer one shared agent. The agent reads logs, traces the bug, and proposes a fix live, so everyone watches the same investigation at once.

The slow part of an incident is rarely the fix. It's the relay: one person digs through logs, types findings into chat, and everyone else rebuilds the picture from secondhand summaries. MobSession cuts the relay out.

Why one shared session beats relaying in chat

Pasting findings into a channel forces every responder to rebuild context in their own head. Details drop, threads fork, two people chase the same dead end. A shared session gives everyone one source of truth: one agent, one transcript, one investigation. When the agent pulls a stack trace or narrows down a suspect commit, the whole group sees it. The next prompt builds on what just ran.

A few things keep a busy incident orderly:

  • Prompts queue and run one at a time. Responders line up ideas and the agent works through them in order. No collisions, no half-finished turns.
  • Contributions are attributed. Every prompt shows who sent it, so the timeline reflects who steered which part.
  • Each turn shows its cost. You see what a turn cost as it runs, which keeps a long incident transparent.
  • The agent runs on the on-call engineer's machine with their access. Same environment, credentials, and tooling the on-call already has, so there's nothing to provision mid-incident.

A suggested incident flow

Use this as a starting template and adapt it.

1. Declare

In your incident channel, say what's broken, the blast radius, and who's on point. Keep it short so you can get into the investigation.

2. Start the session

The on-call engineer runs this in the affected repo:

mobsession start

This launches the shared agent on their machine, with their access to the codebase and environment.

3. Share the link

Drop the session link into the channel. Responders join from anywhere, no local checkout or setup needed.

4. Investigate together

Steer the agent toward the symptoms: point it at the failing logs, ask it to trace the request path, have it correlate the error against recent changes. Because prompts queue, responders can stack follow-ups while a turn runs. Watch the agent reason through the evidence and converge on a root cause as a group.

5. Fix

Once the cause is clear, ask the agent to propose a change. Review the diff together in the session. The on-call engineer applies it from their machine, where the agent is already running with the right access.

6. Verify

Have the agent confirm the fix: re-run the failing path, re-check the logs, watch the error clear. Everyone sees the same green signal at once.

Capturing what happened

Preview. Saved incident timelines and postmortem export are in early access and rolling out to teams.

A clean record is most valuable right after an incident closes. Saved timelines capture the full investigation, who steered which step, and how the team reached the fix, ready to turn into a postmortem. Treat it as a preview rather than a guaranteed feature of every session.

Keep going