Running a calmer incident bridge

Anyone who has sat on a bridge call at two in the morning knows the sound of one going badly. Twelve people on the line, three of them talking at once, someone reading out a dashboard nobody else can see, and every team explaining why its own part is healthy. The incident is real, but most of the noise is not about the incident. It is about the call having no shape.

A calm bridge is not one where people care less. It is one where everyone knows who is deciding, where the facts are written down, and what counts as evidence. None of that needs new tooling. It needs a few habits, agreed before the next incident rather than during it.

Give the call three named roles

Most of the chaos on a bridge comes from roles that are implied rather than named. Name three at the start of every call, out loud, even when the same person ends up holding two of them.

• The incident lead decides. They choose what to try next, who looks at what, and when the incident is downgraded or closed. They do not debug.
• The scribe keeps the timeline. Every finding, change and decision goes into one shared document with a time beside it.
• The communications lead talks to everyone who is not on the call: the service desk, other teams, leadership and, where it applies, customers.

Everyone else on the call is a subject expert. They join because they know a system, and they should be able to leave once that system has been ruled in or out. A good incident lead says so explicitly: thank you, database is clear, you can drop off.

Keep one timeline, written as it happens

The single most useful artefact of any incident is a timeline written during it. Not the one reconstructed the next morning from memory and chat scrollback, but the one the scribe keeps as the call runs. It stops the call going round in circles, because the answer to has anyone checked the load balancer is either in the document or it is not.

Keep entries short and factual, and always record where a fact came from. A line that says the pool size changed at 02:10 is useful. A line that says the pool size changed at 02:10, from the change record for the release, is something the review can rely on.

02:16  Payments API 5xx rate 22% (monitoring alert, payments-api dashboard)
02:19  Database team: connection slots exhausted (database log, 02:13:58)
02:21  Change record: release 4.18 lowered pool max from 50 to 10 at 02:10
02:24  DECISION: roll back pool size to 50 (incident lead)

Ask for evidence, not reassurance

My side looks fine is the most common sentence on any bridge, and it is almost never wrong in the way the speaker means. Each team usually is fine by its own measures. The trouble is that each is looking at a different view, and nobody is looking across all of them.

Change the question. Instead of asking whether a system is healthy, ask what it recorded in the window that matters. Can you share the error count from 02:10 onwards? What changed in the hour before? A record with a timestamp moves the call forward. A reassurance only moves it sideways.

Set a rhythm for updates

Half the interruptions on a bridge come from people who are not on it, asking for news. Give them a cadence and they stop asking. Agree an interval at the start, often every 20 or 30 minutes for a severe incident, and keep to it even when there is nothing new. No change, still investigating the database is an update. Silence is not.

Keep each update to the same four parts, so readers learn where to look: what is affected, what we know, what we are doing now, and when the next update is due.

Call the cause when the evidence agrees, and say how sure you are

There are two moments worth separating. The first is mitigation: the point at which users stop being hurt, often by rolling something back or failing over. The second is the cause: the point at which you can explain why it happened. Bridges often blur them, either declaring victory at mitigation or refusing to mitigate until the cause is certain.

Mitigate as soon as there is a safe move. Name the cause when more than one independent source points to the same thing: the change record, the database log and the error rate all lining up on the same minute. And say how confident you are. Probable, with three sources agreeing is a perfectly good thing to say at 02:30. The review in the morning can firm it up.

Let people go

A bridge that keeps everyone until the end teaches people to dread being paged. Release experts as soon as their system is ruled out, and hand the call over explicitly if it runs past a shift. The person taking over should be able to read the timeline and know everything that matters without asking anyone to repeat it.

After the call

Before the bridge closes, the incident lead should confirm three things: the impact has stopped, the timeline is complete enough for someone else to read, and the follow-up actions have owners. Everything else, including the full explanation, belongs to the postmortem.

Where Pindot fits

None of the habits above depend on any product. Pindot is built for the part of the call where the facts live in many systems at once. It reads those systems with read-only access, lets the team ask in plain language what changed or what went wrong, and answers with the records it relied on and how sure it is. The roles, the timeline and the judgement stay with your people.