Stripe rejects a webhook if the t= value inside the Stripe-Signature header is too far from the current time — by default more than 300 seconds (5 minutes). This tool checks that drift for you, in your browser. It does not need your webhook secret — it only reads the timestamp, which is not sensitive.
Paste your header
The 5 real causes (and the fix)
Server clock not synced (NTP drift). Cloud VMs and containers can drift several minutes if NTP is disabled or the container was paused/resumed. Fix: run timedatectl status (Linux) or check your host's NTP sync; on containers, sync at boot.
You verify the signature after queueing the event for async processing. If the webhook sits in a queue for minutes before verification runs, the timestamp check fails even though the request just arrived. Fix: verify the signature immediately on receipt, before queueing, then queue the already-verified payload.
A retried/replayed event delivered late. If Stripe retries a webhook after your endpoint was down, the retry can carry an old timestamp relative to when you finally receive it. Fix: this is expected behavior — either increase tolerance slightly (not below what your security model allows) or accept the retry will fail verification and rely on Stripe's dashboard/API to replay it manually.
Reverse proxy or load balancer buffers the request body. Some proxies buffer and re-transmit slowly, or a WAF rewrites headers. Fix: check your proxy doesn't strip or delay the request, and that it forwards the header unmodified.
Local/dev testing with a stale captured header. If you saved a header from Stripe CLI or the dashboard and replay it later in tests, of course it's stale. Fix: generate a fresh header per test run (e.g. stripe trigger or the CLI's live forward).
Still stuck, or want your whole webhook flow checked?
This tool checks one symptom. The $39 done-for-you audit reviews your actual webhook handler code — signature verification, idempotency, event dedup — and gives you a written report with file references within 48h.