Aglet

Prioritize webhook retry amplification

Retry storms should queue by work at risk and amplification, not by attempt count alone. A shared endpoint serving writes deserves earlier attention than an optional read. Weigh receipt state, duplicate effects, event age, recovery capacity, and response semantics for the shared receiver.

Decide where the work belongs

  1. Map work at risk

    For each cohort, record event identity, operation, endpoint, receipt state, attempt count, queue age, and side-effect status. Separate new events from retries. Keep a real bounded sample behind claims about loss or duplication.

  2. Compare containment

    Assess pausing optional work, reducing local concurrency, changing one response mapping, or retaining events for review. Record what remains pending and which owner controls sender behavior. Do not add capacity while duplicate work is still unbounded.

  3. Set the storm queue

    Queue pre-receipt loss, unknown writes, and shared retry amplification first. Set owner, finite attempt policy, review time, and evidence threshold. Keep a cosmetic retry message below a response disposition that can multiply events.

What to carry forward

Return a retry queue with effect risk, endpoint reach, attempt evidence, containment, owner, and proof needed to reprioritize. Escalate unknown or irreversible work. Keep rank provisional when sender policy or receipt durability is unobserved. Keep the queue finite while the owner gathers evidence.

Technical background: Twilio documentation.

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