Error Handling in Automation: Build Workflows That Don't Crash

Every automation will encounter an error. The API returns a 503. The input data is malformed. The rate limit is exceeded. The question is not whether errors will happen but whether your workflow survives them. A well-engineered automation handles errors gracefully, logs them, alerts the right people, and continues processing the remaining records. A poorly built one crashes, loses data, and leaves you piecing together what happened from incomplete logs.

This guide covers the four pillars of error handling that separate production-grade automations from fragile prototypes: retry logic, dead letter queues, fallback paths, and alerting. Whether you are building on Make.com, Zapier, or custom code, these patterns apply universally.

Pillar 1: Retry Logic with Exponential Backoff

Most automation errors are transient. An API endpoint is temporarily overloaded, a network request times out, or a database lock causes a brief conflict. Retrying the same request a few seconds later often succeeds. But naive retry logic—immediately retrying in a tight loop—makes things worse by hammering an already-stressed endpoint.

Exponential backoff solves this. The first retry waits 2 seconds. The second waits 4 seconds. The third waits 8 seconds. This gives the destination system time to recover while still resolving the error quickly. Cap your retries at three to five attempts. Beyond that, the error is likely persistent and needs different handling.

In Make.com, configure the error handler on each HTTP module with "retry" directives and set the interval multiplier. In Zapier, use the built-in retry feature for action steps. For custom integrations, implement the backoff calculation: delay = base_delay * (2 ^ attempt_number) + random_jitter. The random jitter prevents multiple concurrent workflows from retrying at exactly the same time and creating a thundering herd.

Figure 1 — Decision flow for handling errors: retry transients, queue data errors, use fallbacks for system errors

Pillar 2: Dead Letter Queues

When retries are exhausted or the error is not transient, the failed record needs to go somewhere safe. A dead letter queue (DLQ) captures every record that could not be processed, along with the error details, timestamp, and the original payload. This prevents data loss and gives your team a clear list of items to investigate and reprocess.

Implement your DLQ as a Google Sheet, Airtable base, or database table dedicated to failed records. Include columns for the error type, the module that failed, the original input data, and a status field (new, investigating, resolved). This turns a chaotic error investigation into a structured workflow. Your team reviews the DLQ daily, fixes the root cause, and reprocesses the records.

Without a DLQ, failed records vanish. You only discover them when a customer asks why their order never shipped or when your monthly reconciliation reveals a gap. In high-volume order-to-cash automation, even a 0.5% failure rate without a DLQ means dozens of lost orders per month.

Pillar 3: Fallback Paths

Some errors cannot be retried because the primary path is down entirely. Your shipping API is experiencing an outage. Your payment processor is in maintenance. Your inventory system is unreachable. In these scenarios, the workflow needs an alternative route.

Design fallback paths for every critical integration point. If the ShipStation API is down, queue the shipping label request in a buffer and process it when the API recovers. If QuickBooks is unreachable, create the invoice record in a staging table and sync it once the connection restores. The key principle is that no order should be lost because a single system in the chain is temporarily unavailable.

Fallback paths must be tested as rigorously as the primary path. Too many teams build a fallback route and never verify it works. When the actual outage hits, they discover the fallback has its own bugs. Include fallback path testing in your pre-launch testing framework.

Pillar 4: Real-Time Alerting

Error handling without alerting is logging without action. Every error path—retry exhaustion, DLQ entry, fallback activation—should trigger a notification. The alert should include the workflow name, the specific module that failed, the error message, and a direct link to the failed execution log.

Tier your alerts by severity:

• Critical (immediate): All retries exhausted for an order-related workflow. Send to Slack, email, and SMS simultaneously.
• Warning (within 1 hour): Retry succeeded but the number of retries is increasing. Send to a dedicated monitoring Slack channel.
• Informational (daily digest): Fallback paths activated, latency above normal, or DLQ entries added. Include in a daily summary email.

Avoid alert fatigue by being precise about thresholds. Alerting on every single retry attempt drowns your team in noise. Alert on patterns: more than five retries in an hour, more than three DLQ entries in a day, or any fallback activation. This keeps the signal-to-noise ratio high.

Putting It All Together

A production-grade automation workflow wraps every external API call in a retry handler, routes permanently failed records to a dead letter queue, activates fallback paths when primary systems are down, and alerts the team in real time when intervention is needed. This is not over-engineering; it is the minimum viable architecture for any workflow that handles real business data.

Figure 2 — Most automations operate at Level 1 or 2. Production workflows require Level 3 or 4.

The time you invest in error handling pays for itself the first time an API goes down at 2 AM and your automation routes around the outage instead of losing 200 orders. Build it right from the start, and you will never wake up to a data disaster.