Aglet

Investigate whether a release explains an error spike

Investigation asks whether the release is a credible explanation, not whether the graphs look close together. Build a comparison that another engineer can repeat: same path, matched time windows, representative examples, and the nearest unaffected control. Preserve evidence links and confidence.

Build a useful investigation brief

  1. Reproduce the timeline

    Plot the release boundary beside error counts, latency, traffic, and relevant job activity. Use equal intervals before and after the change, and record gaps caused by delayed processing or incomplete telemetry. A visual overlap is evidence to test, not proof.

  2. Compare changed and unchanged paths

    Identify the code, configuration, dependency, or routing differences introduced by the release. Compare a failing path with an equivalent path that remained stable. Capture request shape, response, commit context, and environment for each example.

  3. Test plausible alternatives

    Review dependency health, traffic mix, feature flags, data shape, and client distribution. Seek one observation that each alternative predicts and check it against available records. Keep unsupported explanations explicitly unresolved rather than filling gaps with intuition.

What to carry forward

The investigation brief should state the strongest supported relationship, the reproduction steps, linked records, and confidence with reasons. It may conclude that the release is implicated, merely correlated, or not distinguishable from another change; each outcome should name the next evidence needed.

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