Fix connection errors
App modules output the ConnectionError when the app is unavailable. For example, the app might be offline for maintenance.
Make uses the HTTP 503 and 504 status codes to identify the ConnectionError.
Make follows the standard error codes and their definitions. Note that it is possible that the third party may not fully comply with the standard.
When a module in your scenario outputs the ConnectionError, you should check the status page of the module app. Chances are that the status page will have the URL https://status.domain, for example https://status.make.com.
When Make recognizes the module output as the ConnectionErrorConnectionError and you don't use any error handling, Make acts depending on the following attributes:
- scenario scheduling
- enabling of the incomplete executions
| Incomplete executions disabled | Incomplete executions enabled |
|---|---|---|
Scheduled scenario | Make pauses the scheduling of the scenario for 20 minutes. Make doesn't rerun the scenario. | Make pauses the scheduling of the scenario for 20 minutes. Make retries the incomplete execution with the incomplete execution backoff. |
Instant scenario | Make reruns the incomplete execution with the scenario backoff. | Make retries the incomplete execution with the incomplete execution backoff. |
How to fix the ConnectionError
To handle the ConnectionError, you can use the strategies for handling the rate limit errors . The most efficient strategy is to use the Retry error handler to rerun the scenario after a delay:
If your scenario triggers with an instant trigger (for example, a custom webhook module), consider enabling Process data in order in scenario settings. With Process data in order, the trigger module processes incoming data one by one in the order they arrive.
Otherwise, skip this step.
If a scenario has incomplete executions and Process data in order enabled, Make pauses the scenario until the incomplete executions are processed to keep the order of incoming data.
Add the Retry error handler to the module that is causing the errors.
Consider setting the delay and the number of attempts according to the importance and the schedule of your scenario.
For example, if the app has occasional downtime for maintenance for a few hours with no availability, it might be best to set a lower number of attempts with longer time periods between them.
On the other hand, if the app is occasionally unavailable because it's overloaded, and the scenario is important for you, it might be best to use a short time period (a few minutes) with a higher number of attempts.
Enable incomplete executions in the scenario settings. Make will save bundles that caused the error.
For example, if you would use the Webhook trigger to ask questions to ChatGPT, but the ChatGPT app is sometimes overloaded with requests and sending back errors, your Make and Make settings with error handling could look like this:
Whenever the Create a completion module outputs the ConnectionError because the OpenAI servers are overloaded or unavailable, Make creates an incomplete execution with the Create a completion module.
After the delay set in the Retry error handler, Make reruns the Create a completion module. If the rerun succeeds, Make will continue scheduling new scenario runs.
If the rerun fails, Make reruns the module again after the delay, up to the number of attempts set in the Retry error handler settings.