Make.com Scenario Errors: Diagnosis and Recovery

Make.com (formerly Integromat) is one of the most powerful automation platforms available, offering granular control over data flows, advanced error handling, and visual scenario building. However, that power comes with complexity, and scenario errors can be challenging to diagnose if you do not understand Make's execution model. This guide covers the most common scenario errors, their root causes, and proven recovery strategies.

Understanding Make.com's Execution Model

Unlike simpler platforms, Make.com processes data in bundles. A single scenario execution can process one bundle or thousands, and each module in your scenario processes bundles sequentially. An error on bundle number 47 does not necessarily affect bundles 1 through 46; it depends on your error handling configuration. This bundle-based model is critical to understanding why errors behave the way they do.

Incomplete Executions

When a scenario encounters an error and you have "Allow storing incomplete executions" enabled, Make stores the failed bundle for later replay. This is both a feature and a trap. The feature lets you fix the issue and replay the failed data without losing it. The trap is that incomplete executions pile up silently, consuming your data storage quota and creating a backlog you may not notice for weeks.

Diagnosis: Navigate to your scenario, click the "Incomplete Executions" tab, and review the queue. Check the error message on each incomplete execution. Common causes include API timeouts, authentication failures, and data validation errors in downstream modules.

Recovery: Fix the underlying issue first. If it is an expired connection, reconnect it. If it is a data format problem, update your scenario logic. Then replay the incomplete executions in small batches rather than all at once to avoid rate limiting.

Figure 1: Make.com's four error handler types serve different purposes. Choose based on your data criticality.

Connection Errors: "The connection has been lost"

Make.com connections represent authenticated links to external services. They can break for several reasons: the third-party service revoked the token, someone changed the password on the connected account, the service had an outage during a token refresh, or the OAuth scope changed.

Fix: Go to Connections in your Make.com dashboard. Look for connections marked with a red warning. Click "Reauthorize" to re-establish the link. For services that use API keys, verify the key has not been rotated or expired. After reconnecting, run a test execution to confirm the connection works in the context of your scenario.

Operation Limit Reached

Every Make.com plan has a monthly operation limit. Each module that processes a bundle counts as one operation. A scenario with 8 modules processing 100 bundles uses 800 operations per execution. If your scenario runs on a 5-minute schedule, that is 230,400 operations per day, far exceeding most plan limits.

Fix: Optimize your scenarios. Use filters before heavy processing modules to reduce bundle count early. Aggregate records using the Array Aggregator module before API calls. Avoid unnecessary router branches. Review your Make.com setup to consolidate scenarios where possible.

Module-Specific Errors

Each module can produce unique errors based on the service it connects to. Common examples include HTTP 429 (rate limited), HTTP 422 (unprocessable entity), and timeout errors on slow APIs. Make.com surfaces these in the execution log with the full response body, which is invaluable for diagnosis.

Diagnosis: Open the scenario execution history, click on the failed execution, and inspect the errored module. The input data, output data, and error response are all visible. Copy the error response and search the API documentation of the connected service for that specific error code. For rate limiting specifically, see our comprehensive guide on API rate limiting in automation.

Building Self-Healing Scenarios

The most resilient Make.com scenarios are designed to recover automatically. Attach error handlers to every module that makes an external API call. Use the "Break" directive with automatic retry for transient errors. Set up a dedicated error notification scenario that sends you Slack or email alerts when any scenario fails. Log all errors to a Google Sheet or data store for weekly review. These practices transform Make.com from a fragile tool into a production-grade automation platform. For foundational mistakes to avoid, read our guide on common beginner automation mistakes.