Decide where the work belongs
Rank the action left uncertain
Name whether the timeout affects a read, save, assignment, upload, or other durable action. Separate a delayed refresh from a result that may have committed without confirmation. Give higher priority to workflows where people cannot safely decide whether to retry.
Group reach by deadline and shape
Compare route, method, input size, data class, client, network, server deadline, dependency, release, and final-state evidence. Distinguish caller-only timeouts from work that continues or commits afterward. Mark sparse completion samples as uncertain rather than classifying them as failures.
Choose a bounded timeout slice
Select immediate investigation, a deadline or idempotency improvement, or collection of one missing commit trace. State what changes priority, such as duplicate writes or a common blocked workflow. Keep global timeout policy separate from the first route whose completion boundary is unclear.
What to carry forward
Produce a queue decision tied to blocked work, state uncertainty, timeout reach, and retry risk. Include whether the behavior is new or tied to a scale boundary. The next engineer should have one route and input shape where completion can be observed across the deadline.
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