The Make.com Scenario That Ran 10,000 Times and Delivered Nothing
Make.com counted 10,000 operations and delivered nothing. An operation is a module run, not an outcome. Validate response bodies not just status codes.
The Make.com Scenario That Ran 10,000 Times and Delivered Nothing
Make.com counted 10,000 operations. Your account moved into the next billing tier. The scenario was marked as completed successfully.
Nothing arrived in your CRM.
The data was fetched. The records were processed. The iterator ran through every item. The HTTP module fired against the CRM API for each one. The API returned a 200 OK for every request.
The issue: the 200 OK came back from a CRM endpoint that accepts requests even when the authentication token has expired, logs the request as failed internally, and returns a success code anyway. Your CRM has no new records. Make.com has no errors.
10,000 operations. Zero outcomes. Full billing.
Why Make.com Operations Do Not Equal Results
An operation in Make.com is a module execution. The module ran. That is what an operation counts. Whether the module did what you intended is a separate question that operations do not answer.
This is not a flaw specific to Make.com. Zapier tasks work the same way. n8n workflow executions work the same way. Every automation platform counts executions, not outcomes. The conflation of “ran” with “worked” is a universal automation mistake.
But in Make.com the stakes are higher because the iterator pattern makes it easy to process thousands of items in a single scenario run. The gap between “ran a lot” and “worked a lot” is proportionally larger.
The Specific Patterns That Waste Make.com Operations
API responses that are not validated. Every HTTP module should check the response body, not just the status code. A 200 OK with an error in the response body is a failed operation you paid for and did not notice.
Iterator runs on empty collections. If the module that feeds your iterator returns an empty array, the iterator runs zero times but the modules before it still consumed operations. Significant if those modules are doing expensive API calls.
Infinite retry loops. Make.com has a retry mechanism for failed modules. If a module fails in a way that triggers retries, each retry is an operation. A misconfigured retry limit on a frequently-failing module can consume thousands of operations overnight.
Webhook scenarios set to All Methods. If your webhook receives traffic you did not expect (test pings, health checks, accidental duplicates), each reception triggers the scenario. Each trigger is operations.
How to Verify Outcomes, Not Just Executions
Add a verification step at the end of any scenario that writes to an external system:
For CRM writes: after the HTTP module, add a second HTTP module that retrieves the record you just created and checks that it exists. If it does not, route to an error handler.
For email sends: verify the send response includes a message ID. A 200 OK without a message ID from most email APIs indicates the message was queued, not sent.
For database writes: use a query module to count the records in the target table before and after the write. If the count did not increase, the write failed.
Make.com’s error handling documentation at help.make.com/hc/en-us/articles/9267263883037 covers how to add fallback routes for API errors.
The Make.com Operations Audit
| Warning Sign | Likely Cause | Fix |
|---|---|---|
| Operations spike on a normally quiet scenario | Unexpected webhook traffic or retry loop | Check webhook logs, add retry limit |
| High operations, no outcomes in destination | API returning false success | Add response body validation |
| Operations on days the scenario should not run | Scenario not properly scheduled | Review scenario schedule |
| 0 items processed but positive operation count | Pre-iterator modules consuming operations | Add filter before iterator |
The Mental Model That Prevents Wasted Operations
Think of a Make.com operation as “this module was attempted.” Not “this module succeeded.” Not “this module produced the result you intended.”
Every place in your scenario where you assume that a module completing means it achieved something is a potential gap between operations paid and outcomes delivered.
The fix is explicit outcome verification after every critical write, and an alert when verification fails. This adds operations to your count. It also means you know what your operations actually bought.
Frequently Asked Questions
Does Make.com charge for operations from failed modules?
Yes. An operation is charged when a module is executed, regardless of whether it succeeds or fails. Failed modules still consume operations. This is why retry loops on failing modules are expensive.
How do I set a retry limit on a Make.com module?
In the module settings, under Advanced Settings, you can configure the number of retries and the retry interval. Setting a maximum of two to three retries prevents runaway operation consumption on persistently failing modules.
Can I get a refund on operations wasted on a bug?
Make.com’s general position is that operations consumed due to user configuration issues are not refunded, though you can contact their support for extenuating circumstances. Prevention through verification steps is more reliable than seeking refunds after the fact.
How do I find which scenario is consuming the most operations?
In your Make.com dashboard, go to Organization, then Usage, to see operation consumption by scenario. Sort by operations to identify your highest consumers.
The One Thing to Remember
An operation in Make.com is a module execution, not a successful outcome. 10,000 operations can produce zero results if the downstream systems accept requests without completing them. Add response body validation after every HTTP module. Verify outcomes, not just executions. A few extra operations spent on verification are worth far more than discovering a multi-week failure after the operations bill arrives.
Want your Make.com scenarios running on reliable infrastructure? → Snapdock
New here? These might help: Make.com looks complicated. That is the point. → You didn’t ship an automation. You adopted something that dies quietly. →