Keeping n8n workflows running is a job with no title and no owner on the org chart. The workflow ships, the Slack message lands, the row appears in the sheet, and everyone moves on to the next thing. Months later an API key expires quietly, a node is deprecated in an upgrade, and the thing that “just works” stops working on a Tuesday morning when nobody is watching. Building the automation is the easy half. Maintaining it is what decides whether it stays an asset or quietly becomes a liability.
Failed runs are the smallest part of the problem
Failed executions are the visible failure, and they are the right place to start. n8n keeps an execution log for every run, and workflow settings let you attach an error workflow that fires when a run fails. Route that to a channel a human actually reads, not an inbox nobody opens, and include the workflow name, the failing node and the error message so triage does not begin with a login.
The expensive failure is the workflow that runs green and produces nothing: an API returning HTTP 200 with an error body inside, a filter matching zero rows because an upstream field was renamed, a node silently dropping items. Alerting on the absence of output matters as much as alerting on exceptions — assert on required fields, check row counts against what you expect, and add a heartbeat from outside n8n for webhook-triggered workflows. A workflow that never fires never fails, so nothing tells you it is down.
Credentials, upgrades and the slow drift that breaks working workflows
Credentials are where maintenance turns political. Every workflow holds stored secrets — API keys, OAuth client secrets, refresh tokens, webhook signing keys — and each one is controlled by someone outside your team. Providers rotate keys, tighten scopes, deprecate auth methods, and revoke tokens when a password changes or a staff member leaves. The work is not swapping the key; it is knowing every workflow that used it, the order to update them in, and how to prove afterwards that nothing broke. Keep a credential register mapping each secret to its dependent workflows and to the person who can reissue it — and back up the encryption key n8n uses to store credentials, because losing it means re-entering every credential by hand.
Version upgrades carry the same shape of risk. n8n releases frequently, and a version bump can change node behaviour, deprecate parameters, break community nodes that lag the core release, and run database migrations at startup. Treat an upgrade as a change with a rollback plan: pin the image tag, snapshot the database, test on a copy with realistic workflow data, read the release notes for the nodes you actually use, then move production. Skipping upgrades is not stability; it is deferred risk with a worse failure mode.
Documentation is the unglamorous third leg. For each workflow, record what triggers it, which systems and data it touches, who owns it, how to re-run a failed execution safely, and what normal output looks like. Without that inventory every incident starts with archaeology, and the only person who can fix the workflow is the person who built it — the exact dependency a small team cannot afford.
A maintenance routine a small team can actually hold
The cadence matters less than the existence of one. A workable version:
- Daily: triage failed executions and decide retry versus fix; confirm the alert channel is live and not muted.
- Weekly: look for workflows that have stopped firing altogether, and spot-check outputs rather than statuses.
- Monthly: review credentials and tokens nearing expiry, check node versions against the n8n version you run, and confirm execution-data pruning is configured so the database does not fill the disk.
- Quarterly: upgrade on a test instance first, re-read the workflows nobody has touched, and update the inventory.
In-house, hybrid, or handed over
Three questions settle ownership. How many workflows are running, and how badly does the business feel it when one stops? Is there a named person with the access, the time and the authority to touch production? And what response time does the workflow genuinely need — an internal report can wait a day, a quote-to-invoice or lead-routing integration cannot.
A small team with a handful of low-stakes workflows and an engineer who owns them should keep the work in-house; the overhead of handing over exceeds the risk. Once workflows touch customer data, billing or revenue routing — or once the original builder has left and nobody can explain what a node does — the honest conclusion is that maintenance is unowned. That is where managed AI and n8n automation fits: the deliverable is not a demo, it is someone holding the runbook, the alerts and the upgrade plan on a schedule.
Start with an inventory rather than a tool: list every workflow in production, what it touches, who owns it, and what happens if it stops for a day. If any line reads “nobody”, that is your real maintenance backlog. Where the answer is a managed arrangement, Managed Automation — Starter on sakal.shop covers up to 5 monitored workflows with email alerting on failures, a monthly health check and an optimisation review, at S$327 per month including 9% GST (S$300 before GST). The Professional tier raises that to up to 15 monitored workflows with priority support on a 4-hour response SLA and a monthly block of hands-on engineering time, at S$872 per month including 9% GST (S$800 before GST).
Disclosure: Code n Rob is written by the founder of Sakal Network, which runs sakal.shop.
