Don’t use an execution ID
A new workflow execution gets a new ID. Deduplication needs the same stable key for the same logical event.
01 / AUTOMATION RELIABILITY
One event.
More than one delivery.
A retry can duplicate your work. A simple dedupe flag can lose it. See what happens when a webhook worker crashes.
No loginNo webhook requestsNo payload collection
With your permission, we count this session’s visit, runs, completed simulations, download requests, errors and guide clicks with a broad traffic source. No names, emails, identifiers, IP addresses or scenario inputs are saved in our statistics database. Our hosting provider still processes connection data to serve the page. Statistics are optional; your choice lasts for this tab session.
OBSERVEREADY
Where does your retry land?
Run the scenario to inspect each delivery.
WHAT THE MODEL TEACHES
Deduplication and recovery
are different jobs.
A flag can hide lost work
If you mark an event as seen and crash before the action, a retry may skip work that never happened.
The destination matters
After an external action succeeds, a crash can make its result uncertain. A state ledger alone cannot prevent the action happening twice.
Take the pattern into n8n
Implementation guides on DevelopWhale. These links are educational; they are not paid endorsements.
Model assumptions & sources
All deliveries are sequential copies of one fixed event. The first delivery may crash at the selected boundary. A recoverable lease is assumed to have expired before the next retry. Destination idempotency, when enabled, is assumed to persist for the entire scenario. The model does not test concurrent claims, real databases, network timeouts, retry scheduling, key expiry or production configuration. One action in this model does not prove exactly-once delivery in a real system.
Sources: Stripe webhook delivery documentation, Stripe idempotent requests, n8n HTTP Request.