Every write that can be retried must be idempotent
Platforms retry on your behalf: Stripe redelivers a webhook for up to three days, Slack resends if you do not answer in three seconds, Vercel can fire the same cron twice or start a second instance while the first runs. A handler that charges, sends, or deploys once per delivery will do it twice.
Where it bit
The lead-gen cron ran wrangler pages deploy unconditionally on every tick, with the wrangler account cache committed to the repo. Fixed with a token guard and by untracking the cache. In the research: two PaymentIntents four seconds apart for the same customer is the canonical receipt.
The practice
Acknowledge fast, queue the work, and put a UNIQUE constraint on the event id (evt_, update_id, the Slack event id). Send an Idempotency-Key per order on every Stripe POST. Deploys and jobs take a lock (flock -n, Redis SET NX, pg_advisory_lock).
Check it
stripe trigger payment_intent.succeeded # then resend the same event from the dashboard # expect one row, not two; expect 400 for a forged signature
Get this check as a script you can run tonight
What to do with this
If you run a business on something AI built and the checks came back with more than you expected, that is worth a conversation.
We do a free 30-minute Health Check for service businesses that want to know exactly where their biggest leaks are. No slide deck. No pitch. We ask questions, find the gaps, and tell you what we see. If there is no obvious fix, we will tell you that too.
Blinkz finds what is broken in how a business runs, then fixes it. AI only where it earns its place.