Keep Your Automations Running for Months, and After You Leave

T05-L05 · Automation · Level 5 Operator · 18-minute read, plus 5 hours of doing over a month

Nine quiet days

Katrin looks after research IT for a department of five groups. Over two years its n8n server has collected eleven automations: the Monday digest from T05-L04, sample intake for the sequencing core facility, booking reminders for the confocal microscope, and eight more. One Thursday a group leader asks why nobody has confirmed any sequencing samples since last Tuesday. The intake workflow had lost its mailbox login when IT tightened the password rules. It failed every run, and every failure alert went to the PhD student who built it, who had defended his thesis and left in August. Katrin also finds an email from July: the model the digest uses will be retired. It went to the same student.

In a company it's the distributor with the invoice automation. Tobias, who looks after the company's business systems, now runs seven automations. One Saturday an auto-reply loop fills the sales inbox, and the sorting workflow spends in a day what it normally spends in two months. At the year-end audit the auditor asks who changed the invoice workflow in March, and why. Nobody can say.

You are at Level 5 Operator. Many people's work stops when one of these breaks, and the set must keep running when you're gone. This book shows you how.

After this you can

• Keep one register of every automation you run, with its keeper, deputy, logins, model and takeover page.
• Watch four signals for each automation (silence, failures, waiting work and cost) and send every alert to a team channel, not a person.
• Handle a broken automation with a fixed routine: stop, take over by hand, tell people, fix, rerun safely, write it down.
• Take n8n updates, model retirements and changes in connected systems through a test copy, with a dated change log.
• Hand the whole set over so a deputy can run it, and show an auditor what ran, who changed it and what went wrong.

Before you start

• Books: T05-L04, for the duplicate guards, failure lists and takeover pages each automation needs before you can operate it. T17-L05, for deciding which automations deserve keeping at all. T12-L05 for the organisation-wide governance record. The four quadrants come from T01-L01.
• Admin access to your n8n instance, the installation all the workflows run on, and a colleague in IT who runs the server.
• Uptime Kuma, a free, open-source monitoring tool that IT often runs already for its servers. You'll use it to notice when a workflow goes quiet. If IT uses a different monitor that can receive a "still alive" call, use that.
• A team channel in Teams or Slack that at least two people read every working day.
• The model accounts your workflows use, with admin rights, for example in the Claude Console, Anthropic's web page for API keys, billing and limits.
• About 5½ hours: 18 minutes to read, about 5 hours to do, spread over a month so the deputy drill can happen.

Last verified 23 September 2026. Anthropic gives at least 60 days' notice before retiring a model; Claude Haiku 4.5 retires no sooner than 15 October 2026. n8n's self-hosted Business plan, €667 a month, adds single sign-on and Git version history. Uptime Kuma is free. Details for experts at the end of this book.

The idea in one page

At Level 4 you made one automation fail safely. Now you run many, for months, for people who don't know how they work. Five things keep them alive.

1. One register. A single table with one row per automation. Without it you can't watch, update, hand over or show an auditor anything, because you don't know what exists.

2. Four signals. Every automation is watched for the same four things.

Silence is the one people forget. When n8n itself is down, or a trigger (the first node, which starts each run on a schedule or when mail arrives) has quietly stopped, no error workflow fires, because nothing ran. Only a monitor outside n8n notices that something that should have happened didn't.

3. Alerts go to a team, and each alert says what to do. An alert sent to one person's mailbox dies when that person leaves or goes on holiday. Every alert goes to the team channel, names the automation, links to its takeover page, and says the first step.

4. Every change goes through a copy. n8n updates, a model's retirement, a new password rule in IT, a supplier's new invoice layout: each one reaches your automations whether you plan for it or not. You test on a copy with the test set from T05-L03 and the five failure tests from T05-L04, then publish (n8n's word for putting a version live), then write one dated line in the change log.

5. Hand over before you have to. Every quarter, each deputy takes over one automation from its takeover page while you watch. What they stumble on, you fix in the page. That drill is also your training record.

In the four quadrants, operating is a long Structure it ⇄ Understand it loop. You write down what should be true, you watch what is true, and every gap sends you back to rewrite. Choose tools and Build it happen in small steps: a monitor, a workspace, a page.

Worked example: two sets of automations, four quadrants

Follow the one closer to your work. The incidents, names and numbers are typical examples written for this book.

Lab: eleven automations on a department server

Structure it (30 min). Katrin writes what the department needs from her: "Every automation on the department's n8n either works, or someone who can act knows within one working hour. Any of them can be run by a second person. When I leave, nothing depends on me."

Understand it: the register (2 hours over a week). She lists all eleven workflows from n8n's Overview page, which shows every workflow on the instance to its owner, and fills the register by asking each builder. The gaps are worse than the sequencing incident suggested:

• four workflows send failure alerts to a person, and two of those people have left;
• no deputy can open any of them, because on the Community edition only a workflow's builder and the instance owner can, and two use their builder's own logins;
• the Claude Console account, where the model keys and bills live, is run by a former student, and nobody else looks at it or at the models' retirement dates;
• the digest and two others use Claude Haiku 4.5, which Anthropic's page says won't be retired before 15 October 2026, and may be any time after;
• nobody has written down what the microscope reminders are supposed to do on public holidays.

That sends her back to Structure it. Her first sentence was about watching. The real job starts earlier: "No automation stays on the server without a keeper, a deputy and a takeover page. Where a builder has left, the group leader names a new keeper or we switch it off." Two workflows nobody claims are switched off after a two-week notice in the department newsletter, following T17-L05.

Choose tools (30 min). Katrin keeps the department on n8n's Community edition, the free version you run on your own server. The Business plan's shared projects, version history and single sign-on would help, but €8,000 a year is more than the department's automation is worth, and she can cover both gaps by routine. She picks:

• Uptime Kuma, which IT already runs, for silence. A Push monitor gives a web address that the workflow calls at the end of each good run. If no call arrives within the interval Katrin sets, Uptime Kuma alerts.
• One shared error workflow in n8n, set as the Error Workflow of all nine remaining automations, posting to a new Teams channel, Department automations.
• One Claude Console workspace per automation, each with its own API key and monthly spend limit. The Console's Cost page then shows each automation's spending separately.

The alternative for watching would be Langfuse, a tool that records every model call with its cost. It's worth it when you need to see why one answer went wrong. For eleven small workflows the Console's own pages are enough.

Build it: the signals (2 hours). In Uptime Kuma she clicks Add New Monitor, picks the monitor type Push, and copies the Push URL it shows. In n8n she adds a last HTTP Request node, a node that calls a web address, to each workflow and pastes that workflow's push URL. She sets the Heartbeat Interval, how long Uptime Kuma waits for the next call, to fit the schedule. For the sequencing intake, which runs every 15 minutes on weekdays, it's 20 minutes, with a recurring maintenance window so the monitor stays quiet at night and at weekends. For the digest, 7 days plus 2 hours. Each Uptime Kuma alert posts to the same Teams channel.

For cost, in the Console under Settings > Workspaces she clicks Create workspace once per automation, creates a key inside it, and sets a monthly cap on the workspace's Spend limits tab. Each workflow's model credential in n8n gets the key of its own workspace.

The shared error workflow gets one improvement over T05-L04. Katrin copies three register columns (workflow name, keeper and deputy, takeover link) into an n8n data table, and the error workflow looks up the failed workflow there and adds them to the message:

⚠ Sample intake failed at step "Read submission mailbox" (run 18233).
Keeper: Jonas · Deputy: Mia · Takeover: wiki/automations/sample-intake
First step: open the takeover page. Don't retry the run until you have.

Then the waiting work. Every Monday at eight, one small workflow counts the items in each automation's check by hand table and posts the oldest age per automation. Anything older than two working days is marked red.

The Community edition can't share a workflow with a deputy, so Katrin makes the owner login the emergency route: it goes into IT's password vault, and whoever opens it in an incident writes one line in the register saying when and why. She asks IT to create service accounts for the two that used personal logins. And she has the department's IT mailbox added as a second administrator of the Console account, so notices and bills no longer depend on one person.

Build it: the incident routine (45 min). One page, the same for every automation, pinned in the Teams channel:

1. Stop the workflow if it could do harm by running again: open it, click the history icon at the top, Unpublish.
2. Take over by hand using the automation's takeover page.
3. Tell the people who rely on it, in their channel, with what to do meanwhile and when you'll next update them.
4. Find the cause, fix it on a copy, and run the test set and the failure tests.
5. Rerun safely: publish, then let the duplicate guard decide what's still to do. Watch the first run.
6. Write an incident note within a week: what happened, who was affected for how long, the cause, what changed. Half a page.

Build it: updates and retirements (1 hour, then every month). The digest's switch from Haiku 4.5 to Sonnet 5 goes through the test set Lena built in T05-L03, on a copy, and passes. The two other Haiku workflows get the same treatment.

The server's n8n version stays pinned, so it changes only when IT decides. IT updates it once a month, after Katrin has run the test sets of the three most important workflows on a test server with the new version.

The Community edition has no built-in Git version control, so the routine is by hand. After every publish, the keeper downloads the workflow as JSON, the text file n8n saves workflows in, into the department's Git repository, with one line saying what changed and why. Katrin checks once a month that the repository matches what runs.

Build it: audit and data protection (30 min). The sample intake handles the names and email addresses of people who submit samples. The data protection officer keeps the institute's register of processing activities, the list of every process that handles personal data, which the GDPR requires. Katrin sends him the register row, the service account, and how long n8n keeps run data. On a self-hosted instance, n8n deletes run data after 14 days by default; she leaves that setting and turns on Redact production execution data in the intake workflow's settings, so saved runs don't show mail contents.

Understand it: the first drill (45 min). In the quarterly drill, Mia, the intake's deputy, gets a staged incident: Katrin disables the intake's test mailbox login. The alert arrives in the channel in 16 minutes. Mia follows the routine, opens the emergency login, unpublishes, and handles two submissions by hand from the takeover page. She stops at step 5: she doesn't know how to tell which submissions the workflow had already entered. The page gets a line: "Look for the submission number in the LIMS before entering anything."

What it taught Katrin: the sequencing silence was never a monitoring gap. It was a register gap. The alert existed; it was addressed to someone who had left.

Company: seven automations and an auditor

Structure it (30 min). Tobias writes: "The seven automations run on company accounts, are watched on four signals, and every change can be traced to a person, a date and a reason. Finance can show the auditor how a draft bill comes into being."

Understand it (90 min). His register shows the invoice automation from T05-L04 in good shape, with service accounts, a takeover page and a guard. The other six are not. The sales-inbox sorter from T12-L03 shares a model workspace with two other workflows, so its spend limit would stop all three at once. The Saturday bill came from that sorter. Each run stayed under its per-run limit, but with the inbox full of auto-replies, every one of its 96 runs that day was a full one. And n8n's run history had already deleted the March runs of the invoice workflow, so there was no way to see what had changed.

He asks the head of finance what the auditor needs. Under the GoBD, the German tax authority's rules for electronic bookkeeping, the company must keep a procedure documentation: a written description of the IT systems and processes that feed its books, including systems that come before the ERP. The invoice automation is one of them.

Back to Structure it: "Each automation gets its own workspace and spend limit, sized so that hitting it stops that automation only. Every change to a bookkeeping workflow is versioned and reviewed by finance before it goes live."

Choose tools (30 min). Tobias makes the opposite choice to Katrin. He moves the company's n8n to the self-hosted Business plan, for three reasons:

• single sign-on, so people log in with their company account and lose access the day IT disables it;
• version control with Git, so every change to a workflow is recorded with its author and a message;
• environments, a separate test server whose workflows move into production in one reviewed step.

At €667 a month it's the largest cost of the seven automations. The head of finance signs it because the audit question alone took two people a week to answer. The alternative is Katrin's routine, exporting by hand, which works if someone does it every time.

For silence he uses Uptime Kuma push monitors, as in the Lab. For failures, one shared error workflow into the channel Business automations, which the finance and IT teams both read. For cost, one Claude Console workspace per automation.

Build it (3 hours). He sets the spend limits from three months of usage: roughly twice a normal month for each workflow. For the sales sorter that's $40, since the Console bills in US dollars. Hitting the limit makes every model call fail, which shows up as failures in the channel, and the takeover page says what sales does meanwhile: sort by hand. A limit that stops one automation is a decision you can make in advance. A limit shared by three is an outage.

The invoice workflow goes into Git. Its change rule in the register: every change is made in the test environment, runs the five failure tests, and is approved in the pull request by the head of AP before it moves to production. A pull request is the Git step where a second person reviews a change before it's accepted.

With finance he writes the part of the procedure documentation that covers the automation: what it reads, the checks, that it creates drafts only, that posting and payment stay with people, where the change history and incident notes live, and how long each is kept. n8n keeps run data for 14 days by default, so the records the auditor needs live elsewhere: in the ERP's drafts with their run numbers, in Git, and in the incident notes.

Understand it: the auditor's questions. In January, a colleague from finance who wasn't involved answers three test questions from the operations folder: who changed the invoice workflow in March and why (Git: Sandra, a new supplier's invoice layout, reviewed by the head of AP); how many draft bills it created in Q4 (the ERP filter on n8n-ap); and what went wrong last year (two incident notes). It takes her eleven minutes.

In both cases the work that mattered most happened before any monitor was switched on: finding out what ran, on whose login, alerting whom.

Handing over

Operators leave, go on parental leave, change jobs. Do this every quarter, and in full when you know you're leaving.

1. Every automation has a keeper and a deputy who aren't you. If you are the only keeper of anything, handing it over is this quarter's job.
2. No automation depends on a personal account. Logins are service accounts. Workflows live in shared projects (self-hosted: Business plan or higher). Model accounts and monitoring have a team address as contact.
3. Deputies have done a drill in the last three months, from the takeover page alone.
4. The register, incident routine, change log and incident notes sit in a place the organisation owns and backs up.
5. When someone leaves, their n8n account is removed and their work goes somewhere deliberate. When you delete a user in n8n, it asks whether to copy their workflows and credentials to another user or delete them for good. Choose on purpose.

What goes wrong

Alerts addressed to a person. Symptom: a workflow fails for days and the alerts sit in a former colleague's inbox. Fix: every alert goes to a team channel, with the keeper and deputy named in the message. Check the addresses at each quarterly review.

No heartbeat. Symptom: nothing failed, and nothing ran either; the server was down or a trigger stopped. Fix: a push monitor outside n8n for every scheduled automation, with an interval that matches its schedule.

One spend limit for everything. Symptom: one runaway workflow uses the month's budget and every automation stops at once. Fix: one model workspace and limit per automation, sized from real usage, with the takeover page saying what happens when it's hit.

Changes straight into production. Symptom: after an update or a "small fix", a workflow behaves differently and nobody knows since when. Fix: every change on a copy or in the test environment, through the test set and failure tests, with a dated line in the change log.

Evidence that expires. Symptom: the auditor asks about March, and n8n deleted March's runs in April. Fix: keep what an audit needs outside n8n: the change history, the incident notes, and marks in the target system that tie each record to its run.

Retirement notices nobody reads. Symptom: a model's retirement date passes and a workflow stops. Fix: put each model's earliest retirement date in the register, make sure at least two people administer the provider account, and plan the switch at least a month ahead.

Automations nobody claims. Symptom: a workflow runs whose builder has left and whose users nobody knows. Fix: no keeper, no running. Announce a switch-off date, and retire it properly if nobody claims it.

Do it yourself (5 hours, over a month)

1. Structure it (30 min). Write what the people who rely on your automations need from you, in two or three sentences.
2. Understand it: the register (90 min). List every automation on the instance with the columns above. Mark every gap: personal logins, alerts to people, missing deputies, models near retirement, no takeover page.
3. Structure it again (15 min). Rewrite your sentences from what the register showed. Decide which automations to switch off or give new keepers.
4. Choose tools (15 min). Pick your silence monitor, the team channel, and one model workspace per automation. Decide whether your instance needs a paid plan for sign-on and version history, or a routine by hand.
5. Build it: signals (60 min). Add a push monitor and a last HTTP Request node to each scheduled automation, set the shared error workflow in every workflow's settings, set up the weekly waiting-work count, and give each automation its own workspace and spend limit.
6. Build it: routine and folder (45 min). Write the incident routine, start the change log, and put everything in one operations folder the organisation owns.
7. Understand it: the drill (30 min, in the last week). Stage one incident on a test copy and let a deputy handle it from the folder alone. Ask a colleague three auditor questions. Fix every gap they find.

Exit check

What you hand in: an operations folder for the automations you run, with:

• the register, one row per automation with every column filled;
• the alert setup: a heartbeat per scheduled automation, the shared error workflow, the waiting-work count, and a spend limit per automation;
• the incident routine and at least one incident note, real or from the drill;
• the change log, with the version history of each automation that writes to a real system;
• a handover checklist with the date of each deputy's last drill.

It passes when every automation has a keeper and deputy other than you alone, every scheduled one has a heartbeat that alerts a team channel, a deputy handles a staged incident from the folder alone, and a colleague who wasn't involved answers three auditor questions (who changed X, what went wrong last year, what does Y write) from the folder in 15 minutes.

Rule to remember

If an automation's alerts, logins or knowledge belong to one person, it stops when they do.

Details for experts

Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.

Further reading and tools

Next books

• T05-L04 · Make an Automation Safe to Fail Before It Touches Real Systems: guards, failure lists and takeover pages for each automation.
• T17-L05 · Decide Which Problems Deserve Building: which automations to keep, hold or retire.
• T12-L05 · Keep One List of Every AI System Your Team Runs, and Make It Survive You: the organisation-wide record of AI systems, risks and training.
• T03-L05 · Keep a Production Prompt Healthy for Months, and Hand It Over: keeping test sets alive across many prompts and models.
• T16-L05 · Keep Your Toolset Useful: retiring tools, with data, access and accounts.

Tools

• n8n: Taught. Shared error workflow, Insights, projects, Business plan, run data settings.
• Uptime Kuma: Taught. Push monitors for silence.
• Claude API: Taught. Workspaces, spend limits, the Cost page and retirement dates.
• Claude Sonnet: Taught. The model the digest moves to.
• Git: Taught. Version history for workflows.
• Langfuse: Catalogued. Recording every model call and its cost, when you need to see inside individual answers.