Aglet

Prioritize API token expiry incidents safely

Token expiry work deserves different queue positions depending on whether a read is delayed, a write is unknown, or every caller is refreshing together. Weigh durable work, duplicate risk, account reach, and evidence quality. A larger failure count is not enough to justify a broader retry or longer token lifetime.

Decide where the work belongs

  1. Describe the blocked operation

    For each cohort, record the operation, token state, account or workspace, and whether a remote side effect may already exist. Separate reads from writes and pending jobs from interactive requests. Preserve operation identifiers so an unknown outcome can be reconciled safely.

  2. Compare recovery options

    Assess one refresh, a safe readback, a user-visible reauthentication path, a bounded pause, or owner review. Note credential authority and secret rotation dependencies. Do not rank a silent refresh above a visible failure when the original write could be repeated.

  3. Set the expiry queue

    Choose an owner, review time, maximum attempts, and evidence that would raise or lower priority. Put unknown writes and account-wide refresh failures ahead of cosmetic expiry messaging. Keep an individual stale token behind a confirmed lifecycle defect when scope is narrow.

What to carry forward

Return a ranked queue with blocked work, replay risk, credential state, containment, owner, and evidence threshold. Escalate unknown writes and shared refresh failures first. Mark every rank provisional when the remote operation result, clock, or credential lifecycle remains unobserved.

Technical background: RFC Editor reference.

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