Broken n8n order intake, repaired

Self-initiated demo - not a client project. Palewood Ceramics is an invented company.

A broken automation rarely announces itself. It keeps running, it keeps looking green, and it quietly drops work — which is why an invented ceramics studio, written for this demo, only finds out when a customer asks where their order is.

This is a self-initiated demonstration that rebuilds that situation in full. Palewood Ceramics is an invented company. Its n8n workflow pulled orders from the shop into a spreadsheet, a confirmation email and a Slack channel, and four complaints came in: orders missing from the sheet, some customers emailed twice, Slack silent for an hour at a time, and an owner back to checking every order by hand.

The first step was not to fix anything. It was to measure. One ordinary shift was rebuilt as a scenario that can be replayed: 120 orders over five hours, 60 scheduled runs, and the interruptions that really happen — the shop's website restarting for seven minutes, the email service hitting its daily limit, three orders published a few minutes late, four customers correcting their address after ordering, one customer with a single name, one with no phone number, one with an empty email field, one address that bounces forever.

Against that shift, the old workflow lost 14 of 120 orders for good — EUR 2,504 of revenue. It emailed six customers twice, left seven confirmations unsent, and failed ten times without telling anyone.

Every complaint had a different cause. Missing retries meant a few seconds of downtime threw away a whole run — eleven of the lost orders went that way. A fixed "last five minutes" window silently skipped the orders published late, and the safety margin someone had added started duplicating everything that fell into the overlap. One customer with a single name was enough to kill every good order in that batch with it. Nothing checked whether an order had already been handled. And a failed email ended the run before the Slack message that would have revealed it.

The repaired version remembers exactly where it stopped and moves that mark only after an order is safely saved, so a crash can never skip past one. It remembers which orders it has already stored: an identical repeat is dropped, while a genuine correction rewrites the existing row and tells the team — without emailing the customer a second time. Orders are checked one at a time, so one bad record can no longer take good ones down with it, and anything truly unusable is handed to a person in Slack. Everything that still fails — an unreachable shop, an address that bounces — becomes an alert naming what broke and where. The API key moved out of the workflow file into a credential.

Over the same shift: no orders lost, no duplicate rows, no duplicate emails, no failed runs — and four alerts about things a person genuinely needed to see.

None of this has to be taken on trust. The page replays both workflow files against the same shift, in the browser, in well under a second, and prints what each version did, run by run. 45 automated checks confirm that each defect really is in the broken file, that each fix really is in the repaired one, and that every figure above is what the runs produce. The report also names what is still worth doing, and where the replay differs from n8n itself, rather than pretending the job is perfect.

In a real project you get: the cause of each failure written in plain language, the repaired workflow, a replay of your own worst week against both versions, and a monthly watch on the runs — so a failed execution reaches me before it reaches your customer.

Try the live demo: https://flowlab-dev.github.io/demo/automation-repair/