Make.com vs n8n for One-Person Ops: Visual Scenarios That Hide Silent Failures

I have a Make scenario that has been “OK” for eleven weeks. It copies a Stripe event into a Notion database and pings a Telegram chat. The operations graph is a pleasant heartbeat. The Notion database is missing March. Telegram is fine. Stripe definitely charged people in March. The scenario did not error. It also did not write the rows. A router I added in January had a filter that still mentioned a test product ID. Make called that a successful run of the modules that ran. The modules that did not run were not a failure. They were a branch.

n8n will do the same thing with a prettier self-hosted badge. I moved the same job to a Mini PC, watched green executions, and discovered the HTTP node treats a 200 with {"ok": false} as a win unless I say otherwise. Visual automation is good at drawing the happy path. It is shy about the path that did not take a node.

The one-person job these tools actually get

I am not wiring a company. I am wiring a person: Stripe or Lemon Squeezy to a spreadsheet or Notion, a form to email, a GitHub release to a Discord channel, a weekly digest of RSS that I will not open if the digest lies. The scenario is ten nodes or it is too many. The cost of a miss is a customer I do not thank, or a file I do not invoice, or a backup notice I do not see.

Make.com (the product that used to be Integromat) is hosted, billed in operations, and fast to click. n8n is a Compose stack I already know how to break, or their cloud if I am tired of Compose. Both will ship the ten-node job. Both will hide a silence that is not an exception.

What “success” means in each UI

Make counts operations. A scenario that wakes, filters everything out, and goes back to sleep can still be a successful execution with a handful of ops. Incomplete executions exist, and I have ignored them because they look like a queue I will get to. Error handlers exist, and I have not attached them to the Notion module because the scenario was green in the editor when I clicked Run once with a fixture.

n8n counts executions. A workflow that starts on a webhook and ends after an IF node that went the empty way is a success. The execution list is a wall of green. I filter it when I remember. I do not remember on Fridays. Error workflows exist. They fire on exceptions, not on “the IF was false.” A Wait node that waits three days and then hits a dead credential is a success until the resume, and then it is an error I see if I still look at the instance.

The silent class I care about is: the trigger fired, the filter disagreed with production data, no module threw, no page appeared. Make’s incomplete bucket does not always catch that. n8n’s error workflow does not catch that. A row count check would catch that. I did not build a row count check because the canvas already looked like monitoring.

Where Make hides it

Routers and filters. A bundle that does not match is not an error. It is a drop. I have dropped a month of Stripe events because I left a test-mode filter on. The operations chart still looked alive because other scenarios were busy.

Sleep and scheduling. A scenario that runs every 15 minutes against an API that paginates will look healthy while it only ever reads page one. I have paid for operations to fetch page one forever. Make did not call that a failure. The Notion database just plateaued.

Incomplete executions. Useful when a module actually errors and Make parks the bundle. Useless when I never open the folder. I have had incompletes older than my last invoice. They are a dead-letter queue I treat like a junk drawer.

App modules that “succeed” on empty. Gmail “watch” with no new mail is fine. Gmail “watch” that lost OAuth and still draws a green history until the next token surprise is not a story I want from a hosted product, but I have seen reconnect banners I clicked through without replaying the gap.

Where n8n hides it

HTTP nodes and community nodes. A 200 is a pass. Many APIs I use are 200-shaped failures. I now JSON-parse and throw. I did not, the first month, because the node was green in the editor.

Queue mode and a single worker. I have run n8n on a 2 GB box that swapped. Executions started, the process died, the UI later showed a crash if I looked at the right hour. A webhook from Stripe retried. Sometimes. The missed ones were not in an incomplete folder. They were in Stripe’s dashboard as delivered, which was a lie I believed until I compared counts.

Credentials in environment variables I rotated on the NAS and forgot to restart the worker. New executions failed loudly. Resumed Wait nodes failed later, quietly, on a Saturday. Self-hosting did not make me virtuous. It made me the on-call for a canvas.

n8n cloud moves that class of failure back to a vendor. I have used it for a week when the Mini PC was in a box. The silent filters remained my own.

Cost and the incentive to look away

Make’s operation bill trains you to write tight filters. Tight filters drop bundles. Dropped bundles are free-ish and silent. I have tightened a filter to save money and then missed events. The invoice went down. The Notion gap went up.

n8n’s cost is a machine and my time. I do not spare operations, so I over-fetch, I log too little, and I assume the disk will hold execution data until I need it. It will not, if I prune. I have pruned executions and then been unable to prove what Tuesday did. Green was a color. It was not a receipt.

For one-person ops I now pick the cheaper honesty, not the cheaper run. If I stay on Make, I pay for a nightly scenario that counts Stripe events versus Notion rows and pings me on a mismatch. That scenario is ugly and it is the only one I trust. If I stay on n8n, I do the same count in a workflow that is allowed to fail the active one. I do not use the canvas heartbeat as the check.

When I keep Make

When the other side of the integration is a SaaS I do not want to hold a token for on my disk, and when I will not run Compose this quarter. Make’s modules for Notion, Airtable, and a pile of CRMs are faster to click than n8n’s HTTP plus docs. I add the count-check scenario the same day, or I accept I am decorating.

I also keep Make when a contractor has to see the scenario. The UI is a language they already speak. n8n’s editor is fine. It is not the thing I want to screenshare with a bookkeeper on a Thursday.

When I keep n8n

When the job must see a homelab URL, a Tailscale IP, or a Postgres I already run. Make can hit a webhook I expose. I still do not want my NAS as a Make module if I can avoid it. n8n on the same Docker host as the database is a shorter lie.

When I need a real error path I will write in JS for ten minutes instead of clicking five Make modules that almost express it. The Function node is how I turn ok: false into a throw. I try not to build the whole company there. I have built the whole company there.

A rule I tape to the monitor

If the workflow’s only health signal is a green execution list, it is not operations, it is folklore. Add a count, a checksum, or a row that must appear. Read incompletes on a calendar. Do not trust a router. Do not trust a 200. Do not trust a filter you wrote in January.

Make versus n8n is a hosting and a billing decision. The silent failure is a design decision you will copy into both. I run n8n for the jobs that must touch the house, Make for the jobs a human will edit without me, and a stupid nightly diff for anything that moves money or a customer name. The canvas can stay pretty. The diff is the product I actually operate, even when it is a twelve-line script and an ugly Telegram message.

One-person ops does not need a prettier node. It needs a Wednesday where I notice March is missing before a human asks. Neither logo will do that if I only watch the heartbeat they already wanted me to watch.