You built a workflow: new Stripe payment triggers a welcome email, adds the customer to a spreadsheet, and posts a Slack notification. It runs flawlessly for three months. Then one morning, Slack’s API times out for six seconds, and your entire automation stops cold.
Whether that step retries—or silently fails and leaves your workflow half-complete—depends entirely on which tool you’re using and how you configured it. Most operators don’t think about retry logic until something breaks. By then, you’ve already lost data.
What retry logic actually does
Retry logic is the ruleset that decides what happens when a step in your workflow fails. The failure might be a network timeout, a rate-limit response from an API, a malformed payload, or a third-party service returning a 500 error.
Some tools retry the failed step automatically. Others halt the entire workflow and send you a notification. A few do nothing—they log the error and move on, leaving you with incomplete records and no alert.
The distinction matters most when you’re chaining actions across platforms. If step three fails but steps four and five execute anyway, you end up with a customer charged via Stripe but never added to your CRM. Or a confirmation email sent to someone whose payment actually bounced.
How the major workflow tools handle retries
Zapier retries failed steps automatically—up to three times, spaced a few minutes apart. If all three attempts fail, the Zap pauses and you get an email. The retry only applies to the failed step, not the entire workflow. That means earlier steps won’t re-execute, which prevents duplicate charges or double-sent emails.
Make (formerly Integromat) gives you granular control. You can set retry attempts per module, configure exponential backoff intervals, and define fallback routes if retries exhaust. The default is zero retries—if you don’t configure it, a failed HTTP request just stops the scenario dead.
n8n offers retry settings at the workflow level and the node level. You can specify attempts, delay between tries, and whether to retry only on specific HTTP status codes (e.g., retry on 429 rate-limit, but not on 404 not-found). It’s powerful, but it requires you to think through failure modes up front.
Most no-code tools—Pabbly, Integrately, Activepieces—implement Zapier-style automatic retries with little configurability. That’s fine for simple workflows, but it becomes a liability when you need to handle idempotent vs. non-idempotent actions differently.
When retries make things worse
Not every failed step should retry. If you’re posting a payment to Stripe and the API returns a 400 error because the card was declined, retrying three times won’t fix it—you’ll just log three identical failures and delay the workflow.
Worse: if the original request actually succeeded but Stripe’s response timed out before reaching your workflow tool, a retry might charge the customer twice. Stripe’s API is idempotent when you pass an idempotency_key, but most workflow tools don’t generate or pass one by default.
The same risk applies to any action that creates a record: adding a row to a spreadsheet, sending a transactional email via Postmark, or posting to Slack. If the action completed but the acknowledgment was lost in transit, a retry duplicates it.
This is why Make and n8n let you disable retries on specific steps. If you’re calling a non-idempotent API, you’re better off logging the failure and handling it manually than risking duplicate actions.
What to configure before your first failure
Most operators set up a workflow, test it once with clean data, then assume it’s bulletproof. The first failure happens three months later, in production, with real customer data.
Before you deploy any multi-step automation, configure these three things:
Error notifications. Make sure your workflow tool emails or Slacks you when a step fails. Zapier does this by default. Make and n8n require you to add an error-trigger route or enable notifications in settings.
Retry limits. If your tool allows it, cap retries at two or three attempts with exponential backoff. A six-second delay between attempts is usually enough for transient API issues to resolve.
Idempotency keys. If you’re calling an API that supports them—Stripe, Postmark, most payment processors—pass a unique key (usually a hash of the trigger event ID) in your request payload. That way, even if the workflow retries, the API won’t duplicate the action.
One more thing: test a failure scenario manually. Intentionally break an API call—use a bad auth token, or point it at a non-existent endpoint—and watch what your workflow does. Does it retry? Does it notify you? Does it leave the rest of the workflow half-executed?
You’d be surprised how many tools do nothing.
Want more operator-focused breakdowns like this? Subscribe to One Two Three Send—we publish a new deep-dive every day on the tools and tactics that actually matter when you’re running a content business solo.