Aglet

Triage a post-release error spike without guessing cause

A sudden error increase after a release deserves a bounded first look. Capture when the signal changed, which request or job is affected, and whether the same pattern existed before the release. Keep the release as a useful time marker while leaving causality open.

Establish what is happening

  1. Anchor the release window

    Record the deployment identifier, observed start and finish times, and the first reliable error timestamp. Compare those times with the previous known-good interval, including any queue or cache delay that could shift when users see the change.

  2. Bound the affected path

    Group examples by endpoint, job, service, environment, and response class. Note whether failures affect all traffic or a narrow account, region, browser, or feature path. Avoid treating a single noisy sample as the whole incident.

  3. Separate signal from coincidence

    Check for concurrent provider incidents, traffic changes, scheduled jobs, dependency updates, and instrumentation changes. Mark each explanation as observed, plausible, or untested so the brief does not turn timing into a conclusion.

What to carry forward

The triage output is a short scope statement: what changed, where it appears, when it began, and which explanations remain open. Escalate with the deployment attached when overlap is strong and the affected path is reproducible; otherwise keep investigating without naming a cause.

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