Is there an n8n setup that avoids downtime altogether?

I’ve tried self-hosting n8n and using n8n cloud. I’m not great with server admin stuff so self-hosting wasn’t a good fit. N8N cloud feels very dependable.

But one issue that bothers me is that n8n requires updates that cause downtime. If I recommend it as a solution for a client to replace Zapier for business-critical processes, I’d like to have a solution for updating n8n that doesn’t involve missing a bunch of webhooks in the meantime.

My question is: is there a self-hosted or n8n cloud solution that would result in virtually 0 downtime, much like Zapier (or at least when there is downtime, the automations run afterwards)?

1 Like

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

Hey @Giovanni_Segar,

The first step I think is to define what sort of uptime you are after, Nothing really has 100% uptime so you start to look at the 9’s and it really depends on how many 9’s you need. As an example if you were after 5 9’s (99.999%) that would give you just over 5 minutes a year of downtime, If you were happy with 4 (99.99%) that gives you 52 minutes and 3 (99.9%) gives you 8 days.

So this means the tricky bit is when do you schedule in an upgrade, If webhooks can be coming in at any time you would need to stop the other services at the same time to perform the update and have enough time to roll back if needed which isn’t always easy to do.

What I would do is use an event gateway / webhook gateway for the important webhooks so something like Hookdeck / Convoy / SVIX these systems will take your webhooks and pass them on and if the backend service isn’t online it will just keep retrying and let you know when there is an issue.

You could use this with Cloud or Self hosted n8n instances as it is something you would need to manually configure, The Hookdeck team do have a guide on how to do this which you can find here: How to Receive and Replay External Webhooks in n8n with Hookdeck if you wanted to see a bit more.

The downside now though is while you are mostly covered it would be down to the uptime of that service and it goes back to the 9’s again… Having something to handle the webhooks for you though will give you a higher uptime allowing you to upgrade.

Hopefully this helps.

1 Like

@Jon Thanks for the Hookdeck link—that seems like a good option for being able to receive webhooks even despite an update, and it also has rate limiting features which I’ve wondered about with n8n before.

I’ll definitely keep that in mind for the next time I’m having to deal with heavy webhook traffic.

Sorry for the ignorant question, but what is preventing n8n cloud from updating seamlessly the way Zapier and many other cloud platforms do? Updates seem to just “appear” on these platforms without an instance having to restart.

Hey @Giovanni_Segar,

It is probably worth remembering that Zapier is ~7 years older than n8n and has a lot more employees so the main thing stopping it at the moment is probably time and resources :smiley: we will get there though and already have some interesting things coming for self hosted users that may help in the future.

Zapier was likely designed to be a multi-tenent solution so in the world of Zapier they could likely update different components / services to reduce the downtime they also already have their own built in webhook cache. With n8n every cloud instance is a standalone deployment of n8n it has its own space its own container and there is nothing shared this means that you can update your instance whenever you want.

While the Zapier updates do appear seamless though they do still have downtime like any other cloud service.

Personally I like our approach to have users pick when they want to upgrade but I do think we are missing some features like an inbuilt webhook cache or even an integration with a third party solution so you can bring your own.

4 Likes

@Jon Makes total sense, thanks for engaging the question! I much prefer the product that your team has built over Zapier, so kudos to all you’ve done with more limited time and resources.

I do like the ability to choose what version of n8n you’re running, so I see the tradeoffs inherent there. I think a webhook cache was what I had in mind when I was thinking of “0 downtime”—the idea that even if n8n is updating, automations will continue right after without skipping a beat.

In the meantime, Hookdeck looks like a great option with a generous free plan that could solve the majority of what I’m looking for.

Thank you again and keep up the great work :+1:

2 Likes

Hey @Giovanni_Segar,

No problem at all, Sometimes it is nice to answer questions that not based on workflow building :slight_smile:

I have been using Hookdeck myself for a few months now and oddly enough as it is a product I like using I am also part of their Slack community, I look forward to maybe chatting with you over there about Hookdeck

@Giovanni_Segar what percentage of your workflows (also mission critical workflows) are event/ webhook-based vs. Schedule/ Cron based?

I ask as webhook cache would help with ensuring event-based flows are triggered once instance is back up. But this solution would not currently solve Schedule Trigger based flows (also there, I would assume in various cases it doesn’t make sense to execute 4x back to back if it’s a poll-based WF).

Any context you can provide there helps. I work on the cloud team, so we can use these insights to help prioritize and shape a potential solution (for example a webhook cache)

I’d say 70-80% webhook-based, and the schedule ones are almost always polling triggers that would either pull what they need right after or can be manually re-run.

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.