Aglet

Investigate webhook retry backoff behavior

Investigation should show where one failed delivery became many attempts. Build one event, a concurrent batch, a temporary failure, a permanent rejection, and a local requeue case. Trace event identity and response timing while keeping sender-specific limits as evidence boundaries.

Build a useful investigation brief

  1. Build pressure fixtures

    Create one failed event, many simultaneous events, a recovery response, a duplicate after receipt, and a permanent rejection. Record expected attempts, receipt, and effect before execution. Use synthetic event IDs and safe handlers.

  2. Trace each retry owner

    Capture receiver response, sender attempt, local worker retry, queue delay, deduplication claim, and side-effect result. Compare timestamps and IDs. Look for a worker that retries after a sender retry or a status that invites repetition for invalid input.

  3. Vary one pressure source

    Change only response status, handler delay, concurrency, local retry, or sender schedule in separate runs. Compare backlog and effects. If the sender’s retry rule cannot be seen, document the missing evidence rather than assigning a fixed schedule.

What to carry forward

The investigation is ready when controlled pressure shows the first retry amplification and whether receipt or effects already exist. Deliver a finite response or worker change. Keep sender timing and remote delivery behavior explicit where unobserved.

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