The Automation That Said Success and Did Nothing for a Month

The café that asked to be invoiced

"Our bookkeeper is closing August and can't find a single invoice from you after the 11th. Have we lost them, or have you stopped charging us?"

The email is from Gareth, who runs two cafés in Bath, and it lands in the shared inbox of a coffee roaster in Bristol. The roaster is a composite, like everyone in this story: 22 people, a roastery on an industrial estate, an online shop for retail bags and subscriptions, and about 140 trade accounts, cafés, delis and offices, that order through the same Shopify store and pay by invoice on 30-day terms.

Niamh, who runs operations, opens Xero and searches for Gareth's cafés. The last invoice is dated 11 August. She tries three other regulars. Same date.

Then she opens n8n, where a freelancer who has since moved on built the trade invoicing two years ago. The executions of "Trade order to Xero invoice" are a column of green, dozens a day, the latest from eleven minutes ago. She opens one. The trigger ran, the check after it ran, and the node that creates the invoice never did.

A month of trade orders, around 60 a week, has gone out as coffee and come back as nothing: roughly £37,000 delivered and never invoiced. Alun, who founded the roaster, reads the list over her shoulder and asks the question that brings me in: if this one was green and doing nothing for a month, what else is?

One renamed payment method

Niamh finds the cause in ten minutes, in her own change history. In the second week of August she renamed the manual payment method trade customers choose at checkout, from "Trade account (30 days)" to "Pay by invoice (30 days)", because new cafés kept asking whether they had to apply for something first. A small improvement to checkout, made in a settings screen that has nothing to do with automation.

The workflow's second node is an IF that compares the order's payment method with the exact text "Trade account (30 days)". A match goes to the true branch, which creates the invoice in Xero. Anything else, which used to mean a retail order paid by card, goes to the false branch, and nothing is connected to it. From that day on, every trade order took the false branch.

Nothing failed, so n8n had nothing to report. A branch with nothing on it simply ends, the run is marked successful, and the error workflow the freelancer did set up never fires, because n8n's error workflow runs only when an execution fails. By every measure the platform has, this workflow had a perfect month.

Worse, self-hosted n8n deletes execution data after 14 days by default, and nobody changed the default. Half the month's runs are already gone, so the list of what should have been invoiced must be rebuilt from Shopify and Xero, which actually hold the truth.

What else is green?

Niamh shares her screen on the first call, and the first thing I ask for is not the broken workflow. Fixing the condition takes a minute, and she has already done it. I ask for a list of every automation the roaster runs, what each one writes to, and whose login it uses.

There is no list. There are 26 Zaps in two Zapier accounts, one of them the first freelancer's own, 17 workflows on the n8n server a second freelancer set up, and five Make scenarios from a third. None of the three works for the roaster now.

Two things happen on the first day, before any workflow is touched. n8n's execution retention goes up and the last fourteen days are copied out, so no more evidence disappears. And a read-only check goes live for the trade flow: every trade order in Shopify, matched to a Xero invoice by the order number in the invoice's reference field. It changes nothing, produces the list of missing invoices order by order, and tomorrow morning will tell Niamh whether her one-minute fix worked.

Then I tell Alun what I will not do: rebuild 48 automations, or move them all to n8n, or all into code. Most of them can run twice or skip a day without hurting anyone. The audit sorts them by the question the automation rescue blueprint is built on: if this runs twice, or not at all, does it cost money, corrupt a record or reach a customer?

Forty-eight automations, sorted by consequence

The audit takes a week and a half and changes nothing in production. Every workflow is exported, every credential mapped to a person, and every automation gets one verdict. A few of the rows:

Four of the 48 carry nearly all the risk.

The refund scenario is the second surprise. Its Xero step carries Make's Skip error handler, added after errors had switched the scenario off twice. Make's own help page says what that handler does: it keeps the scenario running and marks the run as a success even in case of errors. Every refund whose customer had no Xero contact failed at that step and was recorded as a success. The audit finds nine.

The third is a habit. Dev, who packs orders and looks after the tech two days a week, reconnects Google in n8n every Monday because "it logs itself out". It does: the OAuth app behind it sits in the first freelancer's Google Cloud project, still in testing mode, and Google expires refresh tokens after seven days for apps in testing mode. A weekly outage has passed for a chore.

Three outcomes instead of two

The trade flow is rebuilt first, because it moves the most money. n8n stays as the trigger, since Niamh can read it, and the work behind it moves into a small service with a Postgres database the roaster owns.

The old IF had two outcomes: an invoice, or silence. The new classification has three. An order is trade when its customer appears in a mapping of Shopify customers to Xero contacts, not when a display name happens to match. It is retail when it was paid at checkout. Anything else, a mapped customer paying by card or an unmapped one choosing invoice, lands in a Slack channel with the reason. Nothing ends on an unconnected branch any more.

Behind that sits a ledger. Every order opens a row with the raw webhook and an idempotency key built from the order ID and the action, create-invoice, checked inside a transaction before anything is written. Shopify can deliver the same webhook twice, and the second copy now stops with a line in the log. When Xero is slow and a call times out, the service searches Xero for that order number before it retries, because the first attempt may have worked. And an authentication failure stops the flow and raises an alert, instead of passing along an empty result.

Then come the checks that would have caught August on its first day. Every morning, yesterday's trade orders are matched to Xero invoices by reference, and every difference is posted to Slack. Each workflow gets an expected volume per weekday, so a Tuesday with fourteen trade orders and no invoices raises an alert by lunchtime. And the ledger records which branch every run took, so a branch silent for 30 days lands on a monthly review list.

The estate's one AI step, which picks an account code for each refund, may now choose only among the four codes that exist, with "not sure" allowed, and code checks its choice before anything is written.

A month of invoices, not in one night

That leaves the month itself: 262 trade orders with no invoice. Replaying the list through the new flow would take minutes, and I will not let it run that way, for two reasons.

The first is Gareth, who would open four invoices over breakfast with due dates nobody agreed. How they are dated, and whether the 30 days run from the order or from today, is for Rosie to decide, the external bookkeeper who closes the roaster's books. How the cafés hear about it is Niamh's call: one short email per account, written by a person, before any invoice arrives.

The second shows up in the dry run, which creates nothing. It proposes invoices for eight orders Rosie had already invoiced by hand, when two cafés rang in August and she took it for a glitch. She had typed the order numbers into the line description, not the reference field, so the match by reference said missing. Replayed as it stood, the catch-up would have billed eight orders twice.

So a rule goes in first: before any replay, code also searches the contact's invoices in the period for the same amount, and every near match goes to Rosie instead of into the batch. The rest go out in batches of twenty, each approved by Niamh and each reusing its order's key, so pressing replay twice cannot post twice.

The next rename

A rescue that leaves the roaster dependent on me has only moved the problem, so the last week is handover. Every connection is re-authorized from the roaster's own accounts, and the old keys are revoked. The Google OAuth app moves into the roaster's own Google Cloud project and is published, which ends Dev's Monday reconnect. The key n8n uses to encrypt its stored credentials, until now in one environment file on one server, is recorded and backed up. Each critical flow gets a runbook: what it does, how a failure shows up, how to replay it. Everything else stays where Niamh can edit it herself, each with a volume alert.

Someone will rename something again, because renaming things is part of running a business. Next time it will not take a café's bookkeeper to notice. At six the next morning the check posts to Slack: sixteen trade orders yesterday, thirteen invoices, three orders it could not place, each with its reason. Niamh reads it before the first roast, fixes the mapping, and replays three items that cannot post twice. Rosie closes September without a spreadsheet of missing invoices, and Gareth's invoices arrive in the same week as his coffee.

Whether yours need more than a monitor

Often they do not. If your automations mostly notify, enrich and report, keep them, switch on the failure notifications in n8n, Zapier and Make, and add an expected-volume alert per workflow. If nothing you run moves money, that is enough. Moving platforms will not add safety on its own, as the n8n, Zapier and Make comparison explains.

When a flow creates invoices, posts payments or changes records, and nobody can say what it did yesterday without opening a vendor's execution log, it needs an owned layer: a ledger, idempotency keys, a reconciliation and a replay. The reasoning is in automation platform or owned integration layer. The audit usually lands in the smallest tier of AI workflow automation, and hardening is scoped per flow from its ranked list. The full blueprint has the six ways a green run hides a failure, the audit step by step, and the handover checklist.

Frequently asked questions