What is your goal?
I am exploring ways to build reliable automation workflows and want to understand how experienced users handle errors in production scenarios.
What are some recommended practices for managing failed steps, retries, API limits, and monitoring automation workflows as they become more complex?
Would appreciate insights from users who have experience building and maintaining larger automation scenarios.
What is the problem & what have you tried?
I am trying to understand the best way to design reliable automation scenarios that can handle failures gracefully.
I would like to learn how experienced Make users manage failed modules, retries, API rate limits, and error handling when building larger workflows.
I have explored basic error handling options but would appreciate recommendations and best practices for maintaining stable automation scenarios.
Hi Adnan,
I’d start by making writes safe to repeat. Use the same idempotency key across retries where supported, or an upsert backed by a unique source ID.
Enable Store incomplete executions.
Make supports automatic retries for connection, rate-limit and module timeout errors. Use the Retry handler for other recoverable failures with limited attempts. Send invalid data and permission failures for correction.
For API limits,
control request volume across every scenario sharing the quota. Use bulk operations where available and set Maximum runs to start per minute for instant scenarios. Account for how many API calls each run generates. Make’s rate-limit guidance.
Log the source record ID, failed module, error and execution link.
Alert on exhausted retries, aging queued records and missing expected output. A successful run can still leave a business task unfinished.
For larger workflows, separate intake from processing through a persistent queue with explicit job statuses. Before launch, test duplicate inputs, rate limits and an outage. Verify that recovery produces the intended result once and leaves every unresolved record traceable.
Validate your data.
Enforce that data validation.
When using filters, don’t forget the else condition where nothing matched.
Use the break error handler to resolve rate limits, server timeouts and proper 5** errors.
These steps will handle majority of the errors a Make scenario produces.
One thing I’ve found useful is to separate recoverable errors from business/data errors.
For temporary API timeouts or rate limits, limited retries with backoff usually make sense. But for invalid data or permission errors, retrying the same request often doesn’t help, so I’d route those to a separate error path for review.
For longer scenarios, I’d also keep a small record of the source ID, failed step, error and retry status. It makes recovery much easier when something fails halfway through.
And I’d make sure important operations are safe to retry — otherwise automatic retries can turn a temporary failure into duplicate records or transactions.