Why Automations Fail (and What Actually Fixes Them)

The first time an automation runs, everything works. The 10,000th time, the API you call has a bad day, the database is mid-snapshot, or a zip file is truncated. A workflow that cannot tolerate those moments isn't an automation — it's a new manual task.

The three failure shapes

• Transient — timeouts, rate limits, blips. These succeed on retry almost always.
• Partial — half the batch processed before a crash. You need idempotency, not just retries.
• Permanent — the input is invalid. No amount of retrying will help; alert a human.

Retry with exponential backoff

Retry the transient ones, but spread them out. A naive retry storms the same broken endpoint from every workflow at once. Exponential backoff with jitter — 1s, 2s, 4s, 8s, give up — gets you most of the benefit with none of the collateral damage.

Make every step idempotent

If running a step twice is dangerous, your workflow isn't retryable. Idempotency keys turn 'at-least-once' deliveries into 'effectively-once' outcomes.

Give each run a correlation ID and make your side effects check it. Did we already send this invoice? Did this lead already get a follow-up? The checks are cheap; the duplicate you avoid is not.