Every Make.com user hits the same wall eventually: a scenario that was running perfectly for weeks suddenly shows a red error badge. Maybe it’s a webhook timeout. Maybe an API rate limit. Maybe a module you updated broke the data flow. Whatever it is, you need to fix it — and ideally, build your scenarios so they don’t silently fail next time.
This guide covers every Make.com error type, how to read error logs, the error handling modules you should be using, and how to set up alerts so you know about failures before your team does.
Why Make.com Scenarios Fail (and Why That’s Normal)
Automation platforms are only as reliable as the services they connect to. When Make.com sends a request to Gmail’s API, Shopify’s webhook, or Airtable’s database, it’s at the mercy of that service’s uptime, rate limits, and API changes.
Common root causes:
- Third-party API outages — Google Workspace, OpenAI, and even Shopify have downtime
- Rate limiting — Most APIs cap how many requests you can make per minute
- Authentication expiry — OAuth tokens expire; connections silently break
- Data format changes — A field gets renamed in your CRM, and suddenly your scenario can’t map it
- Timeouts — Make.com enforces a 40-minute scenario execution limit per run
- Bundle size limits — Some modules cap how much data they’ll process in one go
The goal isn’t to eliminate errors entirely — that’s impossible. The goal is to catch them, handle them gracefully, and alert the right person.
The 5 Most Common Make.com Error Types
When a scenario fails, Make.com shows an error type and a message. Here’s what each one actually means and how to fix it:
| Error Type | What It Means | Common Fix |
|---|---|---|
| ConnectionError | Make.com can’t reach the external service at all | Check if the service is down; add retry logic |
| DataError | The data being passed doesn’t match what the module expects | Validate input fields; check for missing required fields |
| RateLimitError | You’ve hit the API’s request cap | Add a Sleep module between requests; reduce polling frequency |
| InvalidAccessToken | OAuth connection expired or revoked | Re-authorize the connection in Make.com; set up reconnection alerts |
| BundleValidationError | Data in a bundle doesn’t pass validation rules | Check array vs single value; use the Iterator module |
How to Read Make.com Error Logs
Make.com’s execution history is your first stop when debugging. Go to any scenario and click the clock icon (History) in the bottom toolbar. Each execution shows:
- Status bubble — Green (success), yellow (warning), red (error)
- Duration — How long the run took; red flags if it’s near 40 minutes
- Operations used — Each module call counts against your plan
- Data IN/OUT — Click any module to see exactly what data entered and left it
The most useful debugging trick: click the numbered bubble on a failed module to expand it, then view the Input and Output tabs side by side. The mismatch is usually obvious — a field expecting a number got text, or a required field is empty.
You can also download execution logs as JSON for deeper analysis. Just click the three dots on any execution and select Download output bundle.
Error Handling in Make.com: The Core Modules You Need
Make.com includes dedicated error-handling modules that most users overlook. These live under Tools > Flow Control and Tools > Error Handlers:
The Resume Directive (Error Handler Route)
The most powerful pattern: attach an error handler route to any module. Right-click the module, select Add error handler, and connect a new route. If that module fails, Make.com executes the error handler route instead of stopping the entire scenario.
- Use “Resume” when you want to log the error and continue processing remaining bundles
- Use “Ignore” when a failure is expected (e.g., a “not found” when looking up a contact)
- Use “Commit” sparingly — it marks failed operations as successful (dangerous but sometimes necessary with legacy APIs)
The Break Directive
Use the Break module from the Flow Control toolset when you want to stop processing an iteration but not the entire scenario. It’s ideal when a specific record fails validation — you break out of that bundle and move to the next one.
The Rollback Directive
If your scenario creates a resource early and fails later, you can use Rollback to reverse the earlier operations. This requires the scenario to support transactions — not all third-party modules do, so check the documentation for each app.
Building Resilient Scenarios: Retry, Fallback, and Alert Patterns
Here are three battle-tested patterns that keep your automations running even when things go wrong:
Pattern 1: Retry with Exponential Backoff
For transient API failures, don’t just retry immediately — that often hits the same rate limit. Instead:
- Set up an error handler route on the module
- Add a Sleep module (start with 30 seconds)
- Route back to the original module using a Router
- Add a counter variable (via Set Variable) to limit retries to 3 attempts
Pattern 2: Fallback Module
If your primary API fails, route the same data to a backup service. Example: if SendGrid fails to send a transactional email, the error handler routes to Mailgun instead. Both modules sit in parallel error-handler paths, and the first successful one wins.
Pattern 3: Dead Letter Queue
For high-stakes scenarios (order processing, payment handling), never just drop failed records. Instead:
- Create a Google Sheet (or Airtable base) called “Failed Operations”
- In every error handler route, add a Google Sheets — Add a Row module
- Include the error message, timestamp, and raw input data
- Review this sheet weekly to spot patterns
Setting Up Error Notifications That Actually Work
Make.com sends email notifications for scenario errors by default, but those get ignored fast. Here’s what actually works:
- Slack channel alerts: Add a Slack module in your error handler that posts to a dedicated #automation-alerts channel. Include the scenario name, error type, and a deep link to the failed execution
- Email digest: Use a data store to collect errors throughout the day, then send one daily summary email — don’t ping your team for every transient hiccup
- Status page integration: For client-facing automations, push errors to a public status page via BetterStack or Statuspage so clients can self-serve
- PagerDuty / OpsGenie: For revenue-critical scenarios (e-commerce order sync, payment processing), escalate to on-call immediately
Pro tip: Set a condition on your notification module so it only fires if the same scenario fails more than twice in an hour. This kills the noise and surfaces real problems.
Make.com Error Handling vs Zapier: Which Platform Handles Failures Better?
One area where Make.com genuinely outshines Zapier is error handling flexibility. Zapier’s approach is simpler — it retries failed steps up to 3 times, then stops. That’s it. You can’t build custom retry logic, dead letter queues, or fallback paths without writing custom code via Code by Zapier.
Make.com’s visual error handler routes and Resume/Break/Rollback directives give you granular control without code. For teams running dozens or hundreds of automations, this alone often justifies switching from Zapier to Make.com.
That said, n8n goes even further with its error workflow node — it can trigger an entirely separate workflow on failure. Make.com is the middle ground: powerful enough for most teams, not as complex as n8n’s code-first approach.
Frequently Asked Questions
Why do my Make.com scenarios keep stopping?
The most common cause is an unhandled error that cascades through the scenario. If any module fails and you haven’t attached an error handler route, Make.com stops the entire execution. Always add at minimum a Resume error handler with a notification module attached to critical scenarios.
How many times will Make.com retry a failed module?
By default, Make.com retries twice on ConnectionError and RateLimitError with a 1-minute interval. For DataError and other permanent failures, it does not retry — those need manual fixes. You can customize retry behavior in scenario settings (Advanced tab > Maximum number of incomplete executions).
Can I set up SMS alerts for Make.com errors?
Yes, but not natively. Use Twilio’s Make.com module in your error handler route to send SMS. For a simpler approach, configure your Slack notification to trigger a phone notification for messages in your alerts channel.
What does “Incomplete executions” mean in Make.com?
An incomplete execution is a scenario run that ended in an error and is queued for retry. You’ll find them in the incomplete executions queue (left sidebar > Incomplete executions). They consume your plan’s incomplete execution storage, so resolve or delete them regularly — especially on lower-tier plans with limited storage.
Does Make.com have webhook error handling?
Yes. For webhook-triggered scenarios, Make.com returns HTTP 200 even if the scenario later fails (unless you configure a custom webhook response). Always validate incoming webhook data with a Router + filter before processing to catch malformed payloads early.
Bottom Line
Make.com’s error handling is one of its strongest features — and one of the most underused. Most users run scenarios for months without ever adding error handlers, then panic when a 3 AM Shopify webhook failure means 47 orders didn’t sync.
The 15-minute fix that saves hours of firefighting: add a Resume error handler with a Slack notification to your 3 most critical scenarios right now. Then build the dead letter queue pattern into your next new scenario. Error handling isn’t optional — it’s the difference between automation you can trust and automation you have to babysit.