n8n or custom script with cron-job? A comparison based on the official n8n documentation: error handling, scheduling, code node.
n8n makes sense when an automation connects multiple systems, runs recurrently, and must remain traceable in case of errors. A custom script with a cron-job is often typed in half an hour, but quickly becomes a silent maintenance burden once an API changes, a token expires, or a colleague needs to understand the logic without reading the code. According to the official n8n documentation n8n is "a fair-code licensed workflow automation tool that combines AI capabilities with business process automation" and thus combines a visual workflow editor with real code where it is truly needed. As of July 2026.
The decision between n8n and a custom-written script is not a matter of faith, but a question of how many systems are involved, error susceptibility, and who will maintain the result later. This article shows, based on the n8n documentation, where the line is drawn and when switching from a crontab line to a workflow is actually worthwhile.
A classic setup of a script and a cron-job initially sounds simple: one file, one schedule entry, done. In practice, however, the script takes on far more once it runs in production. It must authenticate against multiple APIs, parse responses and react to format changes, catch errors instead of silently swallowing them, write logs that someone actually reads in an emergency, and ideally notify someone if a run fails. Nobody writes all of this into the first draft, it accumulates piece by piece, usually only after a run has been silently doing nothing for days. This exact retrofitting is the part that consumes the most time in script-and-cron solutions, not the original automation itself.
n8n replaces the framework of authentication, data processing, and scheduling with pre-built nodes without taking away your code entirely. Where built-in nodes are not enough, there is the Code Node: it runs custom JavaScript or Python directly in the workflow, and for self-hosted instances even with access to external npm modules, as the Code Node documentation describes. In the cloud version, module access is more limited. For the operation itself, you also have a choice: n8n can be self-hosted via npm, Docker, or with providers like AWS, Hetzner, or DigitalOcean, as the self-hosting overview shows. This way you retain control over your infrastructure and data instead of being locked into a pure cloud solution.
The direct replacement for crontab in n8n is the Schedule Trigger Node. It starts workflows at fixed times or intervals, similar to the Unix cron utility, but offers seven configuration types ranging from second and minute intervals to custom cron expressions in six-part format including the seconds field, as described in the Schedule Trigger Node documentation. If you have existing cron syntax, you can adopt it almost unchanged, but you no longer need to maintain your own scheduling in the script and can see directly in the interface when a workflow last ran and when it will run next.
A cron-job that fails reports it in the worst case not at all, and in the best case in a log file that nobody checks automatically. n8n offers a built-in concept for this: for each workflow, you can set a separate error workflow in the settings that starts automatically on failure and receives details like error message, affected node, and execution ID via the Error Trigger Node. Additionally, there is the Stop-And-Error Node to intentionally fail executions under certain conditions, and the Retry-on-Fail option on individual nodes. Details are in the error handling guide. This way you can set up notifications for errors without having to write additional code.
If you are unsure whether a planned automation will remain a lean script or be more worthwhile as an n8n workflow, you can get an honest assessment as part of the NordFlux n8n consulting before investing time in the wrong solution.
Yes. The Code Node runs JavaScript or Python directly in the workflow, so you can still program logic that no standard node covers. With self-hosted instances, you can even include external npm modules, while in the cloud version module access is more limited.
For pure scheduling, yes, the Schedule Trigger Node covers intervals from seconds to months as well as free cron expressions. For system tasks outside of workflows, such as cleaning up log directories directly on a server, a classic cron-job remains useful.
You can set up an error workflow for each workflow that starts automatically on failure and receives error details via the Error Trigger Node. This way you can set up a notification, for example via email or chat, without having to program it yourself.
Not necessarily. If it stays a standalone task without other systems, a short script with a cron-job is often faster to implement and causes less ongoing operational overhead than an additional platform.
Not for many standard workflows, since connections between systems can be clicked together with pre-built nodes. Once you need custom logic, it helps to at least be able to read JavaScript or Python, since the Code Node is designed specifically for that.
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
By default, n8n runs in America/New_York instead of Europe/Berlin. Here is how to correctly set GENERIC_TIMEZONE and the workflow timezone.
The cron expression is almost always correct, the timezone is not. Three real n8n forum cases show why Schedule Triggers fire at the wrong time.
The real question is rarely technology but maintainability: who looks after the automation once the author of the script has moved on? NordFlux advises vendor-neutrally on when n8n is worth the switch and where a cron job remains the more honest solution. You get a recommendation based on your processes, not on a licence catalogue.
