What is a sensible number of attempts?

Fewer than people expect, spaced further apart than people expect. The purpose is to survive a passing fault rather than to outlast a real outage, and a long series mostly delays the moment somebody finds out. What matters more than the number is that reaching the limit produces a signal.

Should every step have the same settings?

No, because steps differ in what a repeat costs. A read can be attempted freely, while a step that creates or sends something to a customer deserves a shorter allowance and closer attention. Applying one rule everywhere is convenient and treats those two cases as though they were the same.

How do we know it is working rather than quietly stuck?

By making the limit visible when it is reached. A workflow attempting the same step for hours looks identical to one running normally unless something reports it, so the setting that matters most is what happens at the ceiling rather than what happens before it.

Glossary

Retry logic

The rules deciding whether a failed step is attempted again, how many times and how far apart, so a passing fault does not become a stopped process.

In plain terms

Redialling a number that was engaged, and deciding in advance how many times you will do it and how long you will wait between attempts. Software makes that decision once and then applies it without thinking, which is its advantage and the reason the settings deserve a moment.

Why it matters

Because most failures between systems are temporary and a few are not, and the same response covers both. A service under momentary load, a network hiccup and a wrong password all present as a step that did not succeed. Attempting again resolves the first two and does nothing for the third except produce the same failure repeatedly, which is why the interesting part of the setting is not how many times but which failures qualify.

How it works

Spacing the attempts is the point, not the count. Repeating instantly against a service already struggling adds load precisely when it is least wanted, and a queue of automations all doing that together is a familiar way to keep something down. Waiting longer after each failure gives the other side room to recover, which is why the pattern is near-universal.

Some failures should never be attempted again, and telling them apart is the real work. A rejected credential or a malformed request will fail identically every time, so repeating it wastes the allowance and delays the alert somebody needs. A timeout or a temporary refusal is worth another go. Tools differ in how much of this judgement they make for you.

The ceiling exists so that failure surfaces. Without a limit a workflow can sit repeating quietly for a long time, which looks like nothing being wrong rather than something being stuck. What matters is less the exact number than that reaching it produces a signal somebody sees.

The reason this needs care at all is that the caller cannot see what happened. A step that reports nothing may have been ignored or may have been carried out with only the confirmation lost, and repeating is safe in the first case and duplicating in the second. That is a property of the thing being called rather than of these settings.

Automation raises the stakes by removing the pause. A person who gets an error twice stops and looks; a workflow applies its rule and moves on, at three in the morning, across every record it is processing. The settings are where that judgement was made in advance, which is why they are worth reading once rather than accepting silently.

Which failures are worth another attempt

The reason this split is the useful one is that the setting most people reach for is the count, and the count is the least interesting part. Raising it makes a passing fault more survivable, which is real, and it makes a permanent fault slower to discover, which is usually worse. A wrong password does not become a right password on the fourth attempt; it produces the same rejection four times while the person who could fix it in a minute has not been told. Tools differ in how much of this they decide for you, and where the distinction is not made automatically it is worth making by hand, because the two columns want opposite treatment. The left wants patience and spacing. The right wants to stop immediately and say so. A single rule applied to both is the common arrangement and it is a compromise that serves neither, which is worth knowing before accepting whatever the defaults happen to be.

Seen in the wild

A workflow that waits longer after each failed attempt rather than repeating immediately against a busy service.
Make
An automation set to stop and raise an alert after a fixed number of attempts, so a stuck step is visible.
Zapier
A self-hosted workflow distinguishing a temporary refusal, which is worth another attempt, from a rejected credential, which is not.
n8n

Common misconceptions

People assume

More attempts make a workflow more reliable.

In fact

They make a transient fault more survivable and a permanent one slower to discover. Attempts against a wrong credential fail identically every time while delaying the alert somebody needs, so the useful setting is which failures qualify rather than how many attempts are allowed.

People assume

Attempting again is always harmless.

In fact

It is harmless where repeating the operation changes nothing, and it creates duplicates where it does not. That property belongs to the system being called, so the safety of the setting is decided somewhere other than where the setting lives.

Telling them apart

Retry logic vs Idempotency

Retry logic

Your side: whether to attempt again, how often, how far apart.

Idempotency

Their side: whether a repeated attempt is safe at all.

One is a setting you choose. The other is a guarantee you are given or refused.

Questions

What is a sensible number of attempts?: Fewer than people expect, spaced further apart than people expect. The purpose is to survive a passing fault rather than to outlast a real outage, and a long series mostly delays the moment somebody finds out. What matters more than the number is that reaching the limit produces a signal.
Should every step have the same settings?: No, because steps differ in what a repeat costs. A read can be attempted freely, while a step that creates or sends something to a customer deserves a shorter allowance and closer attention. Applying one rule everywhere is convenient and treats those two cases as though they were the same.
How do we know it is working rather than quietly stuck?: By making the limit visible when it is reached. A workflow attempting the same step for hours looks identical to one running normally unless something reports it, so the setting that matters most is what happens at the ceiling rather than what happens before it.