A workflow that passes a manual test isn’t necessarily ready to run unattended.
The test tells you the nodes connect and the credentials work. It doesn’t tell you what happens when an API times out halfway through, a webhook arrives twice, or the server restarts while an execution is running.
If you’re moving n8n off your laptop, those are the parts worth spending time on.
Start with what you could lose
Before choosing a hosting plan, figure out where your n8n data will live.
If you’re running it in a container, don’t assume that data survives just because restarting the container worked. Restarting an existing container and replacing it are different things. Your persistent storage needs to survive the latter.
Then think about recovery. Back up the database, but also preserve the encryption key used for credentials. Restoring workflows without being able to decrypt their credentials is not a complete recovery.
A useful test: could you restore the instance somewhere else without access to the original server?
You don’t need an elaborate disaster recovery programme for a small automation. You do need an answer.
Decide what happens when an execution only partly succeeds
Suppose a workflow creates a contact in your CRM, sends a welcome email, and updates a spreadsheet.
The contact gets created. The email request times out.
Now what?
Retrying everything might create another contact. Retrying the email might send it twice if the provider accepted the first request but the response never made it back.
This is why “enable retries” isn’t a complete error-handling strategy.
Where possible, use a stable identifier from the original event to recognise work you’ve already processed. Check whether the services you call support idempotency keys. Be especially careful with payments, messages, and anything else you can’t neatly undo.
For each step, ask: is it safe to run this twice?
Test the webhook from outside your own setup
Use the production webhook URL and make sure the workflow is configured to receive production events.
Check that the public address is correct, HTTPS works, and requests reach n8n through any reverse proxy in front of it. Test with the actual service that will send the event, not only a request from your terminal.
Also check how that service handles timeouts. Some send the event again if they don’t get a response quickly enough.
A duplicate event shouldn’t become a duplicate order.
Make failures visible
An instance can be healthy while a workflow has been failing for three days.
Server monitoring and workflow monitoring answer different questions. You want to know both whether n8n is reachable and whether the automation is doing its job.
Set up an error notification somewhere you’ll actually see it. For important scheduled workflows, consider how you’ll notice a run that never started, too.
Keep enough execution history to investigate failures, but review what you’re retaining. Workflow inputs and outputs can contain customer information or credentials that don’t belong in long-lived logs.
Choose what you want to maintain yourself
Self-hosting gives you control. It also leaves you responsible for updates, storage, HTTPS, backups, and recovery.
That’s a reasonable trade if you want the responsibility. Less so if your only goal is to run a few business automations.
I’m the founder of Darwa, where we offer n8n hosting as part of our AI Agent Hosting service, alongside application hosting and managed databases. The point is to take infrastructure work off your plate.
It doesn’t remove the need to design a reliable workflow. No hosting provider can decide whether retrying your “charge customer” step is safe.
Before you call an automation finished, deliberately break something. Send the same event twice. Make an API request fail. Try restoring a backup.
You’ll learn more from those tests than from another successful manual run.
Top comments (0)