Decide where the work belongs
Rank the failed user action
Name the action that fails and distinguish a harmless refresh from a rejected save, assignment, or verification. Record whether the interface explains the outcome and whether people retry manually. A failure that leaves state uncertain or encourages duplicate submission deserves higher priority.
Group reach and outcome variation
Compare failure groups by route, input, account size, device, release, time window, status, and retry result. Separate confirmed reach from sparse observations. A common recoverable error and a rare data-affecting error may need different owners and urgency even when counts are similar.
Choose a bounded queue decision
Select immediate investigation, a targeted error-handling improvement, or collection of one missing comparison. State what evidence changes priority, such as a failing request class with no safe retry or a release boundary. Keep broad reliability cleanup separate from the smallest affected workflow.
What to carry forward
Produce a queue decision tied to blocked work, confirmed reach, retry behavior, and data uncertainty. Include whether the pattern is new, growing, or unresolved. The item is ready when another engineer has a representative failure and understands why its harm outranks other intermittent symptoms.
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