Last verified 23 September 2026. n8n Cloud Starter costs €20 a month billed yearly, for 2,500 runs a month; Pro costs €50 for 10,000. Claude Haiku 4.5 costs US$1 per million tokens (word-pieces) read and US$5 per million written. Details for experts at the end of this book.

The idea in one page

A workflow that runs on a schedule does the same thing many times without anyone watching. So the question before it runs unattended is:

What is the worst this workflow can do before a person notices?

Answer it in things you can count: rows written, mails sent, money spent, data exposed, hours until someone looks. Then make that number smaller before you add any monitoring. Watching tells you about damage. Narrow access limits it.

Put every action in one of three lanes.

The rule lives in the build, not in the prompt. "Never send email" in a prompt is advice. A credential without send permission is a rule. For each line of your operating rule, write where the build enforces it: a credential scope (one permission the saved login was granted), a guard node (a step that stops the run when something is off), a workflow setting, a spend limit. A line with no enforcement point is a wish, and the workflow stays supervised until it has one.

Limits have to hold across runs. Twenty items per run sounds small. A trigger every fifteen minutes makes it 1,920 a day. So you need three kinds of limit: one per run (a guard that stops an oversized batch before anything is processed), one on time (the run is cancelled if it takes too long), and one that counts across all runs (a spend limit on the model account, which stops every run once the month's money is used).

A stop has two halves. Unpublish stops new runs. It doesn't stop a run already in progress. The timeout setting cuts that one off. Your deputy needs to know both, and needs the access to use them.

Say what state the result is in. An empty shortlist can mean "no new papers" or "the workflow died at 06:01". Every run writes one status line the reader can see: complete, partial or stopped, with counts. No status line for today means it didn't run.

Where Level 3 stops. You can do all of this with a credential you connect yourself, on n8n Cloud or your organisation's n8n. Once the workflow needs a service account from IT, a login that belongs to a system rather than a person, a mailbox or system IT administers, or its own server, it's Level 4: that's T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In and your IT department, not another guard node.

Worked example: two workflows, four quadrants

Both situations use the four-quadrant method from T01-L01 · From Idea to Working Result: The Four-Quadrant Method. Each starts with a workflow that already works and makes it safe to leave alone.

Lab: the morning literature shortlist

Structure it. Jana, the postdoc: "Every weekday at 06:00 the workflow reads our PubMed search and sorts new papers into read, skim and skip. The group uses the shortlist to pick the Thursday journal-club paper. It has to run while I'm away, and anyone in the group must be able to tell whether today's list is complete, and stop it if it goes wrong."

Understand it. She opens the workflow and follows it node by node: Schedule Trigger, RSS Read with the PubMed feed link, the model step asking Claude Haiku 4.5 for a label and a one-line reason, a check step, and a Data Table node that inserts rows into Morning shortlist. Then she asks the worst-case question. The model can't send anything and the feed is public, so the damage is limited to money and the table. The money is small: at 25 papers a day with a title and abstract each, the month costs less than a coffee. Even a feed of 200 would stay cheap.

The real worst case is the one from the conference week. The PubMed link has a limit= value that anyone who edits the search can raise, up to 200. A long batch fills the table with rows nobody can review. And when the run failed, the table looked the same as on a day with no new papers. Nobody could tell the difference.

That changes what she is building. Back to Structure it: "The shortlist must say whether today's run is complete, partial or stopped. A batch larger than we can read stops before the model sees it. Two people can stop it."

Choose tools. Everything stays in n8n, because the workflow already lives there and the group can read it. A Code node, a step that runs a few lines of code, as a guard before the model. The Timeout Workflow setting at ten minutes, since a normal run takes under two. A separate error workflow, a second workflow n8n starts whenever this one fails, that posts to the group's Teams channel. A separate workspace in the Claude Console, a compartment with its own API keys and its own monthly spend limit, here US$10, about ten times the normal month. No new tools: each of these is a setting or a node, and the next maintainer can see all of them.

Build it. The guard sits between RSS Read and the model step. If the batch holds more than 25 items, it stops the run before anything reaches the model:

In plain words: the code counts the items that arrived; if there are more than 25, it stops the run with a message saying why and what to check, and otherwise passes them on unchanged. If you'd rather not paste code, an If node that tests the count, followed by a Stop And Error node, does the same.

The error workflow is a new workflow that starts with an Error Trigger node and posts to Teams; she picks it in the first workflow's settings (three dots, Settings, Error Workflow). A thrown error fails the run and triggers the error workflow, so the group's channel gets a message with a link to the failed execution. After the Data Table insert, a last node writes one row to a Run status table: date, papers read from the feed, rows written, rows sent to the review queue, and complete, or partial if the check step sent some papers to the review queue instead of the shortlist. If the run stops, the error workflow writes stopped with the error message instead. The shortlist view shows today's status row on top.

For the spend limit, her group's Console admin creates the workspace lit-shortlist (Settings → Workspaces → Create workspace; only organisation admins can). Jana makes an API key inside it, pastes that key into the workflow's Anthropic credential in n8n, and sets the workspace's monthly limit. From then on every run's model cost counts against that limit.

Then she writes the operating rule, one page, stored in the group's shared folder next to the workflow link:

Each line of the Limits block names where the build enforces it. When she writes "Never: email", she checks the credential list for the workflow: only the Anthropic credential is in it. There is nothing that could send.

The known-answers test comes before anything else. She takes 20 papers from last month that she and Tobias have already sorted by hand and saves them as a small test feed. The workflow's labels must match on at least 18. It gets 17. Two of the three misses are the same kind: methods papers that use their technique on a different organism, which the model rates skip. She adds one sentence to the prompt about methods papers and reruns: 19 of 20, and the last miss is a paper she and Tobias disagreed about too. The test feed and the expected labels go into the workflow's folder, so the next person who changes the prompt reruns the same 20.

The stop drill comes last. Tobias gets the rule, nothing else. Jana starts a manual run on a test feed of 24 slow items and says "stop it". He finds the workflow, unpublishes it, and opens Executions. The manual run is still going, and he doesn't know what to do with it. That goes into the rule: "A run already going finishes or times out within 10 minutes. Check the status row after that." The second drill takes him under two minutes.

What it taught her: the model step took an afternoon to build. The status line and the stop took another afternoon, and they're what let her go to a conference.

Company: sorting the shared quotes inbox

Structure it. Lea, sales assistant at a lab-equipment distributor: "Every fifteen minutes the workflow reads new mail in the shared quotes inbox and sorts it into quote request, order change, complaint or other, with the product mentioned. The sales team works from the sorted table. It must never reply to a customer, and someone in sales must be able to stop it."

Understand it. Her workflow uses the Outlook Trigger, a model step, a check step and a Data Table. She asks the worst-case question and starts with the credential. She connected it months ago with Connect my account, and has never looked at what it asked for. The n8n documentation lists the default scopes for the Outlook credential, the permissions it asks Microsoft for: they include Mail.Send and Mail.Send.Shared. So the workflow could send mail as her, and from the shared inbox, if a node ever asked it to. Her prompt says "never reply". That's advice to the model, not a limit on the credential.

The second finding is volume. With twenty items per run and 96 runs a day, the guard alone allows almost two thousand mails a day. The auto-reply loop in spring proved that this can happen. Back to Structure it: "The credential can only read. Each run takes at most 20 mails. A monthly spend limit catches any flood across runs. The team lead can stop it."

Choose tools. The same n8n pieces as the lab. For the credential, she uses the Custom Scopes switch on n8n's Outlook credential to keep only what reading needs: openid, offline_access, Mail.Read and Mail.Read.Shared. The first two let n8n sign in and stay signed in; the last two read her own and the shared mailbox. Not Mail.ReadWrite: that one can't send, but it can delete, and the workflow doesn't need to change anything in the inbox. The Claude Console workspace gets a spend limit of US$25 a month, about five times a normal month. The deputy is Murat, the sales team lead, because he's the one who notices first when the table looks wrong.

Build it. She creates a new Outlook credential with the four scopes, switches the trigger to it, and deletes the old credential from n8n, so no node can pick it up by mistake. The guard node is the same as the lab's with MAX_ITEMS = 20. The timeout is five minutes. Her operating rule has the same shape as Jana's, with two extra lines:

The second line matters. The workflow sends customer mail to a model, and whether that's allowed is the company's decision, not Lea's. She asked IT before the first version, and the rule now says what they decided, with a date. If IT had said no, the workflow would sort by sender and subject line without a model, or not exist.

Her known-answers test is 20 mails from last month, with customer names replaced as in T12-L02 · Clean the Copy, Label the Result, Spot the Trap, that Murat sorted by hand. She sends them to a test folder the trigger watches in a copy of the workflow. 19 of 20 match.

Then the access test, the one that makes the rule true. In a copy of the workflow she adds a Microsoft Outlook node that sends a message to her own address, using the new credential. It fails with a permissions error. She saves a screenshot of the error in the test sheet and deletes the copy. If it had sent, the only mail would have gone to herself, and she'd have known the rule was false.

Murat's stop drill goes well the first time. His question afterwards is the real finding: "After I stop it, what do we do with the mails that came in?" The rule gains a line: "While it's stopped, sort the inbox by hand as before. The maintainer reruns only mails after the last status row."

Five tests before it runs on its own

Both workflows went through the same five tests. Fill in one test sheet per workflow, with the date, the result and a link to the execution or screenshot. Use harmless test items: a test feed, a test folder, mail to yourself. Never real customers or real records.

Rerun test 1 whenever the prompt or the model changes, and tests 2 and 3 whenever a credential or limit changes. That's the change rule in your operating rule.

What goes wrong

The rule says what the build doesn't do. Symptom: the rule says "read only", but the credential can send or delete. Fix: for every "Never" line, name the credential scope or missing credential that enforces it. Run the access test. If a scope can't be removed, don't connect that service.

Only the builder can stop it. Symptom: the workflow sits in your personal space, and your deputy can see the output but not the workflow. Fix: share the workflow with the deputy as an editor, or move it to a shared project, and run the stop drill with them.

The per-run limit is the only limit. Symptom: each run takes twenty items, and a busy day still produces two thousand rows and a large bill. Fix: add the spend limit on a separate model workspace. It counts across every run.

An empty result looks like a quiet day. Symptom: the shortlist is empty, and nobody knows whether the workflow ran. Fix: a status row per run, shown where the reader looks. No row means it didn't run.

The deputy gets more than the stop. Symptom: sharing the workflow gave a colleague the use of every credential in it. Fix: that's how n8n sharing works, so keep credentials narrow, as they should be anyway. Pick a deputy you'd trust with what the credential can do.

Execution history keeps what the table leaves out. Symptom: your table stores categories only, but saved executions hold every mail body. Fix: in workflow settings, stop saving successful production executions (the scheduled runs of the published version, as opposed to your test runs) or redact production execution data, and keep failed ones for as long as you need to investigate.

The workflow keeps growing. Symptom: a working shortlist gets a second feed, then a weekly summary, then an email. Fix: every new source, destination or action is a new line in the rule and a rerun of the tests. Stop building when the five tests pass and the group uses the result. Wider data or actions that leave the team go back to Structure it, and possibly to IT.

Do it yourself (3 hours, two sessions)

Use a workflow you already run for your team. If you don't have one, build the T05-L02 · Put AI in the Middle of a Workflow, and Check Every Answer workflow first.

1. Structure it (15 min). Write one sentence: who uses the result, for what next step, how often. Write down the worst the workflow could do before someone notices, in numbers.
2. Understand it (25 min). Open the workflow and each credential in it. List what each credential is allowed to do, not what the workflow uses. Count the worst-case items per day from the trigger interval and batch size. Rewrite your sentence if something surprised you.
3. Choose tools (15 min). Decide the three limits and their values, the deputy, and where the status line appears. Pick values from what the reader can review and what a normal month costs.
4. Build it: access and limits (45 min). Narrow or replace the credentials. Add the guard node, the timeout, the error workflow and the status row. Set up a separate model workspace with a spend limit.
5. Build it: the rule and the tests (60 min). Write the one-page operating rule. Build the 20-item known-answers set with a colleague. Run tests 1 to 4 and fill in the test sheet.
6. Build it: the stop drill (20 min). Share the workflow with your deputy as an editor, with Share at the top of the editor (self-hosted n8n: Business plan or higher). Give them the rule, start a test run, and ask them to stop it. Don't help. Fix the rule wherever they hesitated, then publish.

Exit check

What you hand in: one published n8n workflow with:

• its operating rule on one page, with the enforcement point for every Never line and every limit;
• a test sheet with the date, result and link for each of the five tests;
• the known-answers set (20 items and their expected labels) stored next to the workflow;
• the deputy's stop drill, with the time it took and what you changed in the rule afterwards.

It passes when all five tests pass, the credential can't perform any action the rule forbids, and the deputy stops the workflow from the rule alone while you watch without helping.

Rule to remember

If the credential can do it, the workflow can do it; limit the credential, and give someone else the stop.

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-L02 · Put AI in the Middle of a Workflow, and Check Every Answer: the model step and check step this book makes safe to leave alone.
• T05-L04 · Make an Automation Safe to Fail Before It Touches Real Systems: retries, duplicates and reruns after a stop.
• T12-L02 · Clean the Copy, Label the Result, Spot the Trap: what may go into the model, and text that gives orders.
• T07-L04 · Connect an Agent to a Real Mailbox Without Handing It the Keys: the same limits when a model chooses its own actions.
• T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In: Level 4, when the workflow runs on your own server.

Tools

• n8n: Taught. Guard node, timeout, error workflow, publish and unpublish, sharing.
• Claude API: Taught. The model account with a separate workspace and spend limit.
• Claude Haiku 4.5: Taught. The model in both examples.
• PubMed: Taught. The saved search and its RSS feed.
• Make: Catalogued. The alternative if your team's workflows already live there.
• Zapier: Catalogued. Simpler automations with fewer places to set limits.