Make.com error handling patterns that actually scale
Error handling is the part of Make.com scenarios that most people add last, after the scenario is 'working.' This is the wrong order. Scenarios that handle errors gracefully are fundamentally different in structure from scenarios that don't — adding error handling after the fact often requires restructuring rather than adding. This guide covers the patterns we use in production Make.com scenarios that handle real volume: rollbacks, dead-letter routes, and alerting that actually wakes the right person at the right time.
Understanding Make.com error types
Make.com categorises errors into four types: Error (the module failed and execution should stop), Incomplete (the module partially processed some bundles and failed on others), DataError (the data passed to the module was invalid or malformed), and ConnectionError (the connection to the external service failed). Understanding which type of error you're dealing with determines the correct handling strategy.
Connection errors are almost always retryable. The external service was temporarily unavailable, a rate limit was hit, or a network timeout occurred. Make.com's built-in retry mechanism can handle many of these automatically — configure the 'Allow storing incomplete executions' setting and set a retry schedule. The scenario will retry automatically when the next scheduled run occurs.
DataError and Error require different handling. A DataError means the data flowing through your scenario doesn't match what the module expects — this usually indicates a problem upstream in the scenario, like a field mapping that's returning null when the module requires a value. An Error means the module itself failed, often because the external service returned an error code. Both need explicit handling logic rather than just retries.
Building error handler routes
Make.com's error handler modules — Ignore, Resume, Rollback, and Break — each represent a different response to module failure. Understanding when to use each one is the foundation of production error handling. Most beginners use Ignore everywhere because it's the simplest. In production, you almost never want to Ignore.
Use Resume when the error is expected and the downstream logic can handle the absence of the failed module's output. If you're enriching leads from an optional data source and that source fails, Resume allows the scenario to continue with the data it has, treating the enrichment as optional. Use Break when a specific bundle has an error but you want processing to continue for other bundles — useful in scenarios processing collections where one item failing shouldn't block all others.
Rollback is for scenarios where partial completion is worse than no completion. If your scenario creates a Stripe customer, then creates a CRM contact, then sends a welcome email, and the CRM step fails, you probably don't want a Stripe customer and welcome email to exist without a CRM contact. Rollback reverts any changes made by modules that support it in the current scenario run. Not all Make.com modules support rollback — check the module documentation before relying on it.
Dead-letter routes for unrecoverable failures
A dead-letter route is the path data takes when all retry attempts are exhausted and the failure is unrecoverable within the scenario's normal logic. Every production scenario that processes important data should have one. Without a dead-letter route, failed bundles are either silently discarded or cause the entire scenario to stop, depending on your error handler configuration.
The simplest dead-letter implementation in Make.com: an error handler route that writes the failed bundle's data to a Google Sheet or Airtable base, with the error message, timestamp, scenario name, and the original input data. This creates a recoverable record of every failure — the data isn't lost, and someone can review, fix, and resubmit it manually. It's low-tech but reliable.
For higher-volume scenarios, use a dedicated database table as your dead-letter queue. When the error handler fires, write the failed job details to the dead-letter table using a Make.com HTTP module or a dedicated database module. Build a separate 'reprocess dead letters' scenario that runs on a schedule, reads unprocessed records from the dead-letter table, attempts to reprocess them, and marks them as resolved or escalated based on the result.
Alerting: waking the right person at the right time
Bad alerting is almost as bad as no alerting. If every minor error in every scenario sends a Slack alert, the alerts become noise and people stop reading them. If only critical errors alert, minor errors accumulate silently until they become major ones. The goal is alert routing that matches urgency — different error types and severities should reach different people through different channels.
Define three alert tiers before building any alerts. Critical alerts (scenario processing has completely stopped, data is being lost, a customer-facing action failed) go to PagerDuty or a phone call to the on-call person. Warning alerts (increased error rate, retries happening, non-critical failures) go to a dedicated Slack channel where someone will see them during business hours. Info alerts (successful completions, daily summaries, non-actionable diagnostics) go to a separate channel or a dashboard, not to any person.
Include enough context in every alert to take action without investigating. An alert that says 'Scenario failed' is useless. An alert that says 'Lead enrichment scenario failed for 3 bundles in the last hour. Error: Clearbit API returned 429 (rate limit). Last affected lead: company@example.com. Dead-letter records created in row 47-49 of [sheet link]' is actionable. Build your alert messages to answer: what failed, why, when, how many times, and where to find the failed data.',
Scenario health monitoring
Make.com's built-in scenario logs are useful for debugging individual failures but inadequate for monitoring scenario health over time. You can't easily see whether a scenario's error rate has been trending up over the past week, or whether a scenario that should run every hour has silently stopped running. Building external monitoring for your critical scenarios is necessary for production reliability.
The monitoring pattern we use: a dedicated 'health check' scenario runs every 15 minutes and verifies that each critical scenario has run within its expected interval and that its error rate is within bounds. This requires maintaining a log table — each scenario run writes a completion record with timestamp, bundle count, error count, and duration. The health check queries this table. If a critical scenario hasn't run in twice its expected interval, the health check alerts.
Track scenario duration as well as success and failure. A scenario that normally takes 2 seconds and starts taking 45 seconds is about to fail — something has changed in the external services it calls. Duration trending up is an early warning sign that catches issues before they become failures. Include average and p95 duration in your weekly operational review for every business-critical scenario.
Related articles
The Make.com playbook: 12 automations every SaaS should run
From lead routing to churn alerts — the scenarios that quietly pay for themselves.
Complete Make.com Guide: Everything You Need to Automate Your Business
The definitive Make.com guide — scenarios, modules, routers, and production patterns.
Make.com Tutorial: Build Your First Scenario in 20 Minutes
A beginner-friendly walkthrough of Make.com — from signup to a working automation.