Set the webhook timestamp tolerance to the provider's documented window - 10 minutes here - not a guessed 5. Server clock skew of a few minutes is normal, so a hardcoded 5-minute window fails legitimate deliveries while the agent's own well-synced machine passes. Read the real window from the docs, make it a named constant or config value, and the skew failures stop.

```text
agent hardcoded a 5-minute timestamp tolerance  -  the provider allows 10 minutes and clock skew killed half the deliveries
```

## Steps

1. Find the timestamp tolerance in the provider's webhook docs: the maximum allowed difference between the event timestamp and now. Write down the number and its units.
   Expected: You can quote the documented tolerance window with its units.

2. Replace the hardcoded value in the handler with the documented window, as a named constant or configuration value - not another magic number.
   Expected: The tolerance is a named, configurable value matching the docs.

3. Confirm the check uses the absolute difference so both early and late timestamps are judged fairly, and that it rejects only timestamps outside the window.
   Expected: Timestamps inside the window pass from both directions; only genuinely stale or future-dated events are rejected.

4. Replay previously failed deliveries whose timestamps fall inside the documented window and confirm they now verify.
   Expected: Deliveries with normal clock skew verify; only out-of-window events are rejected.

## Use this when

- signature checks pass but timestamp checks fail intermittently
- failures cluster on some hosts or containers but not others
- the tolerance value was hardcoded by the agent rather than read from the docs

## Not for this skill when

- the digest itself mismatches - that is a raw-body, encoding, or secret problem
- verification fails on every delivery identically - look at the signature computation first
- you are tempted to disable the timestamp check entirely - do not, it bounds replay attacks

## Variant phrasings

### webhook timestamp tolerance too strict
### clock skew webhook failures
### timestamp outside tolerance
### webhook timestamp check failing

## Why it happens

Agents pick round numbers when the real value is buried in a paragraph: 5 minutes feels safe and standard. But tolerance windows exist precisely because clocks disagree - containers drift, VMs pause, NTP hiccups - and a few minutes of skew is ordinary. The agent's own machine was well synced, so its tests passed while half the production fleet failed, which is why this one hides until deploy.

## Edge cases

- Never set the tolerance to zero: normal skew would break every delivery
- Never set it huge either: the window bounds replay attacks, so keep it at the documented value
- Check the units: some providers stamp seconds, others milliseconds - mixing them up fails everything
- NTP drift on containers can exceed 5 minutes after a host sleep, so monitor skew, not just failures

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AGcb-W8QoANJYpmTM0NPCA