# Take over an incident by confirming four things first

Establish impact, active changes, unresolved outcomes and ownership before starting another intervention. A brief read-back can prevent a costly assumption.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Read the current summary and check its time

Identify what users can and cannot do and when that observation was made. Open the relevant live evidence if the summary may be stale.

Distinguish service recovery from outstanding business reconciliation. For example, successful new orders do not establish the outcome of orders accepted during an earlier timeout window.

Ask for clarification of missing scope before changing the system. Do not assume that an unmentioned component is healthy or untouched.

## Inspect active mitigations and pending actions

List paused jobs, changed limits, feature flags and emergency permissions. Confirm which changes remain necessary and their reversal conditions.

Find any action already in progress and its owner. Starting another intervention against the same component can make the result impossible to attribute.

Review ruled-out hypotheses briefly so the team does not repeat them without new evidence. Keep the current working hypothesis separate from confirmed cause.

## Accept responsibility explicitly

Restate the current impact, active state and next safe action to the outgoing lead. Record the time you accept the incident role and identify the next stakeholder update owner.

If specialist work remains with the outgoing team, name that responsibility rather than assuming every task transfers together. The incident lead and technical task owners may be different people.

Keep one authoritative current summary even when discussion continues in several tools. Conflicting status notes create avoidable uncertainty for responders and stakeholders.

## Act and update the evidence

Before the next intervention, record its purpose, expected signal and stop condition. After execution, record the observed result and update the current summary if the operating state changed.

For a synthetic queue recovery, resume only the verified-safe group first and observe its effect before expanding. Keep uncertain commands under their reconciliation owner.

When closure conditions are met, assign remaining cleanup and review work in the normal tracking system. The handover record should retain links so temporary mitigations and data corrections do not disappear when the live incident channel becomes quiet.

## Sources

- [Google SRE: incident response](https://sre.google/workbook/incident-response/)