Failure class
Make scenario stopped on 429 Too Many Requests
The symptom
A scenario processing a large batch stops part way through. Re-running it from the top duplicates everything it already wrote.
What the log shows
module 4 HTTP → GET /v2/contacts?page=7
← 429 Too Many Requests retry-after: 30
module 4 error handler: none
scenario STOPPED
bundles processed 312 / 1041
The question that separates the causes
Was anything already written before it stopped?
retry-after and you are done.Verdict
The API told you exactly how long to wait — retry-after: 30 was in the response — and nothing was listening. If the header is absent instead, it is an unpublished burst limit and needs exponential backoff rather than a fixed delay.
The fix
- Right-click the failing module → Add error handler → Break. Break stores the incomplete execution so the scenario resumes rather than restarting.
- Set the retry interval to at least the value in
retry-after. - Reduce the batch size so a single run stays under the limit.
Hardening
Make the write idempotent — upsert on a natural key instead of create — or checkpoint progress. Without that, any retry mechanism still duplicates on the paths it does not cover.
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.