The email came at 8:47 in the morning from a client asking why their weekly report had not arrived. I opened my laptop already knowing, the way you know when you have been doing this long enough, that something had failed silently. Not crashed. Not errored out in a way that triggered the notification workflow I had set up. Just stopped producing output at some point during the previous twelve hours while the n8n execution log showed a row of green checkmarks all the way through.
The failure was in a Code node that was aggregating data from three different Airtable API calls into a single object before passing it to the report generation step. One of the Airtable bases had been reorganised by someone on the client’s team. A field name had changed from status to task_status. The Code node was referencing the old field name, getting undefined back, and handling it by passing an empty string into the report template, which then generated a report with blank columns and no error, because technically nothing went wrong. The workflow received data, processed it, sent an email. The email just contained nothing useful.
This is the fragility that does not get discussed in the documentation, the tutorials, or the product comparison pieces. It is not about uptime or server availability or whether your Docker container restarts correctly after a reboot. It is about the gap between a workflow that runs and a workflow that does what you think it is doing, and how that gap can be invisible for weeks before someone notices.
I have self-hosted n8n on AWS EC2 long enough to have experienced most of the loud failures. The webhook URL pointing at localhost because the WEBHOOK_URL environment variable was not set correctly in the Docker Compose file. The SSL certificate that renewed successfully but then stopped being picked up by the nginx reverse proxy because the volume path in the container had drifted after an update. The production workflow that failed silently for two days because I had rebuilt the container without correctly remounting the data volume, so n8n was running with a fresh database and had simply forgotten all its credentials. These failures are painful but they are at least visible. The container is down or the workflow is erroring or the client is not receiving anything, and you find out.
The silent data shape failure is different. The workflow runs. The execution log is green. The downstream system receives something. And somewhere in that something is a wrong field value, a missing record, a calculation that evaluated against undefined and produced zero, and you find out when a human notices that a number is wrong or a report is incomplete or an approval that should have triggered did not trigger.
The n8n documentation on error handling explains how to attach an error workflow at the workflow level and how to configure error outputs on individual nodes. What it does not explain clearly, and what I had to figure out through trial and a significant amount of error, is that not all failures produce errors. A Code node that references a property that does not exist returns undefined rather than throwing. An IF node that evaluates against undefined will take the false branch without flagging anything. A Set node that maps from a nonexistent source field will produce an empty value in the destination field and move on. The error handling infrastructure only helps you when the tool knows something went wrong. For the class of failure where the tool does exactly what you told it to do and what you told it to do was based on an assumption that is no longer true, there is no built-in protection.
Make.com has the same problem and handles it less transparently. In a complex Make scenario with nested iterators, when a module inside the iterator fails on a specific item, Make’s default behaviour is to continue processing the remaining items and aggregate them into the output, with the failed item either dropped or represented as a partial result depending on your error handling configuration. The scenario execution status shows as completed. If you are not specifically watching the operation count and comparing it against the expected input size, you will not know that two records out of forty were silently dropped. I rebuilt a client’s data sync that had been running in Make for eight months and discovered during the migration that it had been dropping approximately five percent of records for an unknown period of time because of an edge case in how Make handles null values inside an iterator. The client had never noticed because the records being dropped were a consistent subset that nobody happened to query.
The fix for this class of fragility is not in the tool settings. It is in building verification into the workflow itself. A downstream step that counts the output records and compares against the input count. An explicit check for required fields before processing rather than after. A Set node at the start of each major processing step that surfaces the data shape you are assuming rather than just using it. These are not features the tutorial will walk you through because they do not demonstrate the tool’s capabilities. They demonstrate the opposite: an acknowledgement that the tool will do exactly what you tell it and that you need to be more careful than you think about what you are telling it.
The most fragile workflows are not the complex ones with twenty nodes and three branches. They are the simple ones that have been running unattended for six months while the world they were built to interact with has quietly changed around them.
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.
