Workflow / Autopsy

Failure class

Duplicate records that survive rebuilding the Zap

The symptom

A payment or form webhook creates two records instead of one. Not every time. The Zap has been rebuilt and re-authenticated more than once, and it keeps happening.

What the log shows

11:03:19Z  webhook  evt_3Pk92f  payment_intent.succeeded
11:03:19Z  Create record  rec_A   OK
11:03:41Z  webhook  evt_3Pk92f  payment_intent.succeeded
11:03:41Z  Create record  rec_B   OK

The question that separates the causes

Is the event id the same on both deliveries?

Same idThe provider redelivered. Webhook delivery is at-least-once by design and every major provider does it — Stripe, Shopify, GitHub, all of them. Nothing upstream is broken, which is exactly why rebuilding did not help.
Different ids, same payloadThe source system genuinely fired twice. Fix it at the source; your Zap is behaving correctly.
Same id, and your endpoint was slow or returned non-2xxYou caused the redelivery by not acknowledging in time. This is the one people miss: slow workflows generate their own duplicates.

Verdict

Same id, 22 seconds apart, is expected provider behaviour meeting a consumer that has no dedupe key. The bug is the missing key, not the delivery.

The fix

  1. Add a lookup step keyed on the event id before the create step, and exit if it already exists.
  2. Where the destination supports it, use upsert on a natural key instead of create — simpler and race-free.
  3. Acknowledge the webhook immediately and do the slow work afterwards.

Hardening

If duplicates appear only under load and never reproduce when you test by hand, it is a different problem: two runs reading before either writes. Manual tests are serial, so they cannot reproduce it.

Re-authenticating and rebuilding cannot fix this, because nothing on the provider side is wrong. That is the signal: a fix that should have worked and did not is telling you the cause is elsewhere.

Still not it?

Send the workflow export and the execution log of one failing run. Within 24 hours you get a written diagnosis: the exact line in your own log that caused it, the fix in your own UI, and a corrected workflow file you import yourself. No account access, no credentials, no call. If the artifacts do not contain the answer, the report says so and it is refunded.

Send an autopsy request →

Or write to hello@workflowautopsy.com.

Other failure classes