Make.com
Excellent for connecting tools, thin where failure matters
The canvas is the best in this category. What decides whether you regret it is what happens to a run that fails at three in the morning.
The verdict
Make.com is the right tool for automation that moves data between cloud services, where a rare failure can be re-run by hand. It is the wrong tool for a process that must be provably recoverable. That belongs in a job queue.
The visual builder handles branching and data transformation better than most of its competitors, and non-engineers genuinely can read what a scenario does.
The limits are operational. Billing counts work per item rather than per run, and recovering a failed run depends on a setting many teams never turn on.
In short
5 things that decide this
- 01Operations are the billing unit. A module generally spends one operation per bundle it handles, rather than one per scenario run.
- 02That makes loops expensive. A hundred items through three modules is three hundred operations, not three.
- 03When a scenario ends unexpectedly because of an error, the run is discarded unless you have configured the scenario to keep it.
- 04Kept failures land in an incomplete executions store, which Make's API refers to as a DLQ, where they can be examined, edited and retried.
- 05For automation whose failure has to be provably recoverable, a job queue is the honest answer.
For someone who has not used it
Make.com connects cloud applications. You draw a scenario as a chain of modules, a trigger starts it, and data flows from one module to the next.
Two things separate it from the simpler tools. Branching and data mapping are properly visual, so complex routing stays readable. And iterators let one incoming item fan out into many, which is powerful and is exactly where the billing surprises begin.
Where it fits in an operations stack
Make earns its place at the edges of a business, joining systems that were never designed to talk. A form submission becomes a CRM record, a task and a notification, and nobody writes a service to do it.
It stops earning its place in the middle. Once a process handles money, legal duties or anything a customer will chase, the questions change. Can you prove this ran? Can you replay what failed? Those are queue questions, and a canvas answers them poorly.
Go4Gr8 shows the split working well. The platform itself is React and FastAPI on AWS with MCP commitment-tracking tools. Make.com sits alongside it, handling automation between services. Core logic in code, joining work on the canvas.
- TriggerOne event starts the scenario.
- ModulesEach item, each module, counts.
- IteratorOne bundle becomes many.
- ErrorRun discarded unless kept.
- RetryOnly from the stored queue.
The fourth station is the one to configure before launch. By the time you need it, the run you wanted is gone.
Where it stands
Good at
- The visual canvas handles branching and data mapping better than the simpler automation tools, so complicated routing stays readable.
- An operations manager can open a scenario and understand it, which matters more than elegance when the maintainer is not an engineer.
- The connector library covers ordinary business software, so most integrations need no custom work.
- Failed runs can be stored, inspected, edited and retried, which is a genuine recovery path once it is switched on.
Weak at
- Operations billing counts per item per module, so a loop over a hundred records costs a hundred times what the diagram suggests.
- A scenario that ends unexpectedly because of an error has its run discarded unless you configured it to store incomplete executions first.
- There is no real version control. Comparing what changed between two versions of a scenario is nothing like reading a diff.
- Long scenarios become hard to read on the canvas well before they become hard to run, and handing one over is a real cost.
- Data passes through a vendor's servers, which is a conversation your compliance team will want if the payload is sensitive.
Automation running unattended
Common questions
01Make.com or n8n?
Choose Make when the work crosses cloud services, nobody wants to run infrastructure, and the canvas is the handover document. Choose n8n when the automation touches your own database, needs arbitrary code, or has to run on infrastructure you control. Self-hosting is the deciding question far more often than features are.
02Why is our operations count higher than expected?
Almost always a loop. Operations are consumed per item per module, so an iterator over a hundred records running through three modules spends three hundred operations rather than three. Filter items out before the loop, and keep the number of modules inside it small.
03What happens to a scenario that fails overnight?
By default the run is discarded when a scenario ends unexpectedly because of an error. Turn on storage of incomplete executions and the failed run is kept instead. You can then read the bundles that caused it, fix the problem and retry. Choose between those two outcomes before launch, not after an incident.
04When should a scenario become real code?
When somebody needs to prove it ran. Guaranteed execution, retries with backoff and a lasting record of every attempt are queue features. Build them on a canvas and you get something that mostly works. Mostly is fine for internal alerts. It is not fine for anything a customer is owed.
