Aglet

Triage a delayed symptom after a software release

Delayed onset weakens simple before-and-after reasoning. Preserve the symptom’s first reliable observation, then map releases, jobs, configuration changes, traffic shifts, and data conditions through the gap. The goal is a bounded timeline with several plausible change points.

Establish what is happening

  1. Mark first reliable onset

    Choose the earliest trustworthy error, latency, customer report, or failed completion and record its source and timestamp. Separate detection time from likely occurrence time when processing or reporting is delayed.

  2. Fill the intervening window

    List deployments, migrations, scheduled jobs, flag changes, dependency events, configuration edits, and traffic shifts between release and symptom. Mark each as observed, inferred, or not checked.

  3. Bound the affected behavior

    Describe the endpoint, job, service, environment, customer segment, and data condition involved. Compare whether the symptom is new, intermittent, or a recurrence that only became visible later.

What to carry forward

Triage should produce a timeline with onset uncertainty, intervening changes, affected scope, and open explanations. Escalate when the delayed symptom affects a critical path or remains unexplained across multiple change points; avoid naming the release as cause from timing alone. Keep detection and occurrence separate in the record, especially when queued processing or scheduled work can move the first visible error away from the initiating change.

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