Aglet

Triage a replayed webhook delivery

A valid signature does not by itself prove that a webhook is new. Freeze one repeated delivery and record event identity, delivery time, receiver clock, prior processing state, and effect. Keep sender retry, manual replay, network replay, and old business timestamps separate.

Establish what is happening

  1. Capture event identity

    Record event and delivery identifiers, endpoint, environment, signed timestamp, receiver time, and prior receipt result. Redact payload and secret. Note whether the same event was previously accepted, rejected, or left pending.

  2. Compare freshness and history

    Check timestamp age, clock difference, deduplication record, and side-effect state for the repeated event. Compare a new event with an old business timestamp. A historical event is not automatically a replay if its delivery is fresh and expected.

  3. Bound repeated effects

    Group repeats by event ID, delivery ID, endpoint, source, age, and outcome. Separate safe duplicate acknowledgement from a second side effect. Keep identity-unknown events in review rather than accepting them as retries.

What to carry forward

Triage ends with event identity, delivery age, prior state, observed effect, and explicit clock or sender gaps. Hold the side effect while freshness is uncertain. Route deduplication, replay policy, and clock questions separately. Keep a valid signature separate from event freshness.

Technical background: Coinbase developer 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