Self-hosted n8n: who maintains it inside a company and the 4 tasks that only show up in month 3

The n8n server was installed in March. In April nobody touched it and nobody needed to. In May someone asked for a text change and it was solved in twenty minutes. In June there is a workflow stopped since Friday because of an expired credential, a list of fifteen requested changes that nobody executed, a version several releases behind and an execution history that already stores tens of thousands of entire customer conversations. Nobody has any of that assigned, because in March maintenance was honestly zero.

That lag is what breaks the self-hosted decision, far more than the installation: the budget is drawn up in month 1, when there is nothing to do, and the discussion about who takes charge arrives the day something is already down. In steady state the work is between 4 and 8 hours a month spread across four tasks, and the month they show up it is not six hours but twelve to fourteen, because they arrive with the backlog of the two previous months on top.

It is held up by one of three figures —the IT area, the person who built it or a provider on a monthly retainer— and each of the four tasks should have a name written next to it before June arrives.

Two things this article is not. It is not the choice between n8n cloud, self-hosted Community and enterprise: that comparison, with the list prices of each model, is in the n8n guide for SMBs. And it is not a guide to setting up the server. It is the math of who holds it up afterwards, measured in hours and in names.

In month 1 maintenance looks like zero, and that is true

In month 1 everything is at its best possible moment, and not by luck: the credentials were issued last week, the database is empty and the installed version is the latest one that existed on the go-live day. A system that has just been delivered does not need maintenance because time has not passed over it yet. Nobody is lying when they say there is nothing to do.

Why an automation degrades on its own even if nobody touches it —what breaks it, how often and how much each break costs— is told in full in one-time payment or monthly subscription. Here we take it as known and go straight to the part nobody budgets for: when that work arrives, how many hours it is and who does it.

It arrives in two uneven batches. The first is the queue of changes the business starts asking for from the first week —a text, a schedule, a price, a public holiday— and that somebody writes down somewhere without executing; by month 3 that list has around fifteen items. The second is the three infrastructure tasks, which make no noise before day 60 and then show up almost together. The result is a month 1 of zero hours, a month 2 of one loose hour and a month 3 of twelve to fourteen, most of which is not that month's work but the backlog of the two previous ones.

The four tasks of month 3, with the hours each one takes

These are typical ranges for a small installation —5 to 12 workflows, a single server—, not the measurement of one specific client: the last row is the one that varies the most depending on how much your business changes.

Define the retention of the execution history. It is a two-hour technical task —one parameter, a number of days and a first deletion that has to be done with the database running— hanging off a decision that whoever executes it cannot take alone. Inside every stored execution is the full content of what went through the workflow: the exact text of the message your customer sent, their phone number, their email and, depending on the industry, also their ID number, the reason for the medical enquiry or the amount they asked to finance. By default all of that is stored in full and forever.

The volume arrives sooner than it seems. A single workflow that runs every 10 minutes generates 144 executions a day, around 13,000 in 90 days. Add a WhatsApp bot that logs one execution per incoming message and after three months you have tens of thousands of entire customer conversations archived, on a server nobody ever inventoried as a personal-data database because nobody thought of it that way.

The two questions that have to be answered are business questions, not systems questions. How many days you need to be able to open an old execution to resolve a complaint —30 is usually enough, 90 is generous— and what you do the day a customer asks you to delete their data. With 90-day retention that second answer is bounded and verifiable; without retention, their messages are spread across tens of thousands of rows nobody knows how to go through. What you notice first, though, is neither of the two: it is that the executions panel takes longer and longer to open, and that symptom shows up months before anyone asks the right question.

Update the n8n version. The project releases new versions very frequently, so after three months you are already several behind. The work is not pressing a button: it is reading what changes, testing that the important workflows still run and having a way back if one of them does not. It is 3 to 4 hours the first time and 2 to 3 every time it is repeated, with a reasonable cadence of every 6 to 8 weeks. There is a silent variant worth checking before month 3: if nobody pinned the version at install time, the next server restart can leave you on a newer version nobody chose, on any random Tuesday and with no test in between. Checking it takes two minutes and it is the only thing on this list that is settled by looking at one configuration line.

Renew credentials and accesses. The tokens and account authorizations you connected on day 1 start expiring or becoming orphaned between month 2 and month 6. It is the most irregular of the four tasks: three months in a row are zero hours and one month is three, almost always at the worst moment. Inside a company it also has a shape of its own that does not appear when a provider is the administrator: half of those connections are made with the personal account of whoever set them up. Calendar goes in with the user of whoever built the workflow, Drive with the email of someone in admin, the WhatsApp number is registered to the mobile phone of someone in sales. The day that person changes area or leaves, the workflow does not die from an expired token: it dies in the offboarding, the same afternoon IT deactivates their account, and nobody connects one thing with the other for two days.

What turns this into zero hours is a three-column sheet written once: what each credential connects to, which account it goes in with, and who can re-authorize it without asking anyone for permission. If that third column has a person's name instead of a company account, that row is an incident with a date on it.

Execute the changes the business asks for. It is the biggest one, the one nobody budgets for and the only one that grows over time instead of stabilizing. A new price list is not one change: if the price appears in the bot's reply, in the quote template, in the payment-due notice and in the dashboard, that is four workflows touched and tested. The same goes for a public holiday that was not there, a new branch or a product that leaves the catalogue. Between 2 and 4 hours a month with 5 to 12 active workflows, and it goes up as you automate more. Add the time spent translating the request when whoever makes it is not the one who executes it: make the bot warn earlier is three decisions —warn whom, how many hours earlier, with what text— that did not come inside the request.

Month 3 does not cost six hours: it costs fourteen

In steady state it is about six hours a month and that number scares nobody. The problem is that the month they show up for the first time is not a steady-state month: it is the catch-up. The initial deletion of the history, 2 hours. The first version update with tests, 4. The two or three credentials that already expired or are registered to somebody who is no longer there, 2. And the queue of fifteen items accumulated since the first week, between 4 and 6. That is 12 to 14 hours in a single month against a budget that said zero.

That is the bill for the lag and it is paid only once, if somebody pays it. If not, it does not disappear: it becomes the permanent state of the installation, where every task is done late and with the previous version on top, which is exactly the scenario in which an update stops being two hours and becomes a project.

There is a second distortion, and it is the one that decides who ends up doing the work. Three of the four tasks require understanding the business and not just the server: to touch the price list in four workflows you have to know which list is current, and to decide whether an update happens on Thursday you have to know whether Thursday is closing day. That is why maintenance sticks by default to the only person who understands both halves, who is almost always the one who built it. If that person is external, how to know in advance whether they will still be answering in month fourteen is in n8n freelancer or agency. If they are internal, the problem is the one below.

What six hours a month of your people cost

Take the total monthly cost of the person who would do these tasks —salary with employer contributions, roughly salary times 1.5— and divide it by 160 hours. Multiply by 6. If that person costs the company USD 2,400 a month, the hour comes out at USD 15 and steady-state maintenance is about USD 90 a month. The catch-up month, about USD 200.

Nobody decides anything with those numbers, and that is exactly the point of doing the math: discovering that the cost is not there. Six hours are not paid in money, they are paid in priority. The question that does decide is which project they come out of: if the person who administers the ERP spends six hours on n8n, something gets done later that month, and it is better to choose what before a Thursday emergency chooses it for you. The second question that decides has nothing to do with price either: what happens during the two weeks that person is on holiday.

From there comes the practical rule. Write the four tasks in one column and next to each one a name with a backup. Three conditions for that table to be worth anything:

• That no name appears four times. If the same one shows up in all four rows and it is not a provider under contract, you do not have a maintenance plan: you have a single point of failure in the shape of a person.
• That no row is left empty. Nobody does that task until it becomes an incident, and the one most often left empty is the first, because it is the only one nobody chases you about.
• That the backup has executed at least one of the four at some point. A backup who has the password but has never logged in is not a backup: it is a name written down so the table looks complete.

The message to send today so the four tasks get an owner

Copy it and send it as an internal message to whoever administers n8n today. It is written for your own people; if it is maintained by a provider on a retainer, what you have to ask for is something else and it is at the end.

Hi, I need to write down who keeps n8n running from here on. It is four things and there is no wrong answer: 1) which version is running and when was it last updated? 2) does the execution history get deleted automatically after a few days or is everything stored since day one? 3) is any of the connections made with someone's personal account instead of a company account? 4) the change requests for the workflows, who do they reach and how many are written down and not done today? If you do not know any of them off the top of your head, tell me and we will look at it together.

All four are answered in ten minutes if somebody is really maintaining it. What matters to you is not so much the answers as which of the four comes back with an I have to check: that is the task with no owner today. And if the fourth one comes back with a high number of requests written down, you already know how heavy the catch-up is before you get to the six-hour steady state.

Three signs that you already have a part-time role nobody created

Putting names and hours in place covers you as long as you have a single environment, fewer than ten or twelve workflows and none of them moving money in real time. Past that point what you have is not an incomplete table: it is half a person working on this without appearing on any org chart or in any budget. You recognize it by three things:

• The change queue went over four hours a month three months in a row. That is no longer maintenance: it is a part-time role nobody created, held up by someone who has another job and another boss. The discussion becomes in-house or outsourced, and that math is in hiring someone or outsourcing.
• The version update keeps being postponed because there is nowhere to test it. A second n8n for testing costs the same as the first, a few dollars a month; the expensive part is the hours of keeping both of them similar. As long as it does not exist, row 2 is done on production on a Sunday or it is not done at all, and both options are bad.
• The backup has never executed any of the four. It is the easiest one to fix and the one most often postponed: doing the history deletion once, with the main owner sitting next to them, costs one hour and turns a written name into a person who has already logged in.

If the conclusion is that somebody external should hold it up, two decisions come one after the other. Whether that is paid as a monthly retainer or as a block of hours is in one-time payment or monthly subscription, and what that agreement has to say in writing —deadlines, detection, third-party changes— is in what to ask for in the contract and the SLA.

The fifth question is the one you cannot send as an internal message

The four in the message above are answered by whoever administers n8n. The fifth one you answer yourself, and it is not sent over chat: which of the four rows you can leave without a backup without it hurting. If the honest answer is none of them, you already know that the split you have today depends on one single person not taking a holiday.

With the five answers side by side you can see the only figure that orders the decision: whether what you have ahead of you is six hours a month of steady state, or twelve to fourteen of catch-up before getting to that steady state. Fairly often the conclusion is that your people hold it up perfectly well and that the only thing missing is writing the four tasks with a name next to each one.

The five answers fit in a single message and you do not need to give us access to anything for us to read them. Paste them into info@striqtech.com and we will tell you which step your installation is on today.