Aglet

Triage a rollback when serving state is uncertain

Rollback language often compresses several different states into one reassuring word. Start by distinguishing the decision to roll back, the deployment state, the version serving traffic, and the behavior observed afterward. Keep each boundary tied to evidence.

Establish what is happening

  1. Separate rollback states

    Record the original deployment, rollback decision, rollback deployment or artifact, status transitions, and timestamps. Mark whether each record reflects intent, progress, completion, or desired state rather than treating them as equivalent.

  2. Identify current exposure

    Capture environment, service, cohort, route, and version evidence for traffic after the rollback point. If exposure is unknown, state that directly and preserve the affected customer path as open.

  3. Check symptom movement

    Compare the original error or behavior before and after the claimed rollback using the same path and time boundary. Note delayed processing, traffic changes, and any evidence that could make recovery look earlier or later.

What to carry forward

Triage should produce a rollback state statement, current exposure boundary, symptom comparison, and evidence gaps. Escalate when serving version or customer impact is unknown; avoid saying recovered until runtime and behavior evidence agree. Separate the rollback request from evidence that traffic changed, and record the last known served version so an unconfirmed intention does not become a recovery claim.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow