agent hardcoded a 5-minute timestamp tolerance - the provider allows 10 minutes and clock skew killed half the...
Fixes webhook timestamp checks that reject legitimate deliveries because the agent hardcoded a 5-minute tolerance while the provider allows 10. Normal server clock skew then fails half the fleet. The fix reads the tolerance from the docs and makes it configurable. Use when signature checks pass but timestamp checks fail intermittently. Not for digest or secret mismatches.
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.
agent hardcoded a 5-minute timestamp tolerance - the provider allows 10 minutes and clock skew killed half the deliveriesSteps
- 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.
- 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.
- 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.
- 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
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.