The workflow had been running fine for six weeks. Then, at 2:47am on a Tuesday, it stopped. Not with an error, which would have been useful. It just stopped. The execution log showed a green checkmark on every node up to the HTTP Request that was supposed to hit the internal ERP endpoint, and then nothing. No failure. No timeout. No response code. Just the particular silence of a workflow that decided, without explanation, that it was done for the evening. I spent forty minutes checking credentials, restarting the n8n container, reading the same three-year-old GitHub issue that everyone finds and nobody has resolved, before I realised the ERP vendor had quietly rotated the API key and sent the notification to an email address nobody checked anymore.
I think about that night whenever someone tells me enterprise companies are too risk-averse to touch open-source automation tooling. Mercedes-Benz apparently did not get that memo.
The news that Mercedes-Benz has moved parts of its internal automation infrastructure to n8n is interesting for a specific reason that most of the coverage has missed. It is not interesting because a large company chose a scrappy open-source tool over an enterprise vendor. That story has been told enough times to be boring. It is interesting because of what it says about what enterprise IT departments actually need from automation tooling, as opposed to what automation vendors have been selling them for the past decade.
What Zapier sells you is convenience, and for a long time convenience was enough. You connect two apps, you move data between them, you avoid writing code, everybody is happy. The problem is that Zapier’s pricing is built for that simplicity, and the moment your workflows get complex enough to be genuinely useful, you have crossed a threshold where you are paying an amount that is very difficult to justify to anyone holding a budget spreadsheet. I have had that conversation with clients. It does not go well. You end up explaining that yes, the tool costs this much per month, and no, you cannot reduce the number of tasks without reducing what the automation does, and yes, I understand that the number seems high for something that is essentially moving data from one box to another. The conversation ends in one of two ways: they pay it and resent it, or they ask you to find something else.
Make.com is the something else that most people find first, and I have spent enough time inside it to have a considered opinion. The canvas is genuinely better than n8n’s for workflows that are visually complex, the kind where you are routing across eight different paths and you need to see the whole thing at once without losing your mind. The iterator logic is cleaner to set up for someone who is not comfortable with JSON. But the moment you need to do something that Make.com did not specifically design a module for, you are in territory where the gap between what the UI suggests is possible and what you can actually make happen becomes significant. I migrated a client’s lead enrichment flow from Make.com to n8n last year and there were two modules in the original build that had no direct equivalent. One I rebuilt with a Code node and about thirty lines of JavaScript. The other required restructuring the logic of the entire flow because the way Make.com had abstracted the API interaction was hiding something important about how the endpoint actually worked. That was not Make’s fault, exactly. But it was a consequence of a UI that optimises for getting started quickly at the cost of making the underlying mechanics visible.
n8n does not optimise for getting started quickly. The first time someone self-hosts it, they will almost certainly misconfigure the WEBHOOK_URL environment variable, point it at localhost, and then spend an hour confused about why their webhooks are not receiving anything. The documentation will not immediately help them, because the documentation describes what the variable does without being direct enough about the specific way it breaks when wrong. I know this because I did it, and I know at least four people in the n8n Discord who did it in the same week.
But here is the thing about that friction. It exists because n8n gives you access to the actual mechanics of what is happening. When I built the invoice approval flow using OpenAI function calling, I could see the exact JSON being constructed and sent. When I connected Claude via HTTP Request node, I could inspect the raw response, understand why the trailing slash in the base URL was causing the 404, and fix it without waiting for a platform update or filing a support ticket. The tool does not abstract away the parts that matter. That is annoying when you are setting it up, and it is exactly what you want when something breaks in production.
Mercedes-Benz did not choose n8n because it is cheaper than the enterprise alternative, though it is. They chose it, or should have chosen it, because at a certain scale and complexity the abstraction that makes tools easy to start with becomes the thing that prevents you from understanding and controlling what your automation is actually doing.
The Fortune 500 IT departments paying attention are not looking at n8n and seeing a startup tool that punches above its weight. They are looking at it and recognising that they have been paying enterprise prices for managed complexity that was never serving them as well as the invoice suggested.
That is a different kind of attention. It tends to produce different decisions.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.
