Use caseWorkflow automationCustom software

Fixing n8n, Zapier and Make automations that report success and did nothing

An audit and repair for inherited n8n, Zapier and Make automations: a run ledger, idempotency keys, reconciliation and alerts, so success means it happened.

A blueprint, not a client story. The business described is illustrative; the architecture, integrations and trade-offs are real, and this is how I would build it. By Ergini, September 11, 2026.

The short version

An audit and repair for companies running dozens of n8n, Zapier or Make automations built by people who have moved on. I map every workflow and what it writes, then harden the few that move money or change records: a run ledger in Postgres, idempotency keys so a retry cannot post twice, a dead-letter queue, daily reconciliation against the destination system, and Slack alerts when volume drops. Credentials move into your own accounts, and people approve every replay that touches money.

Best for: Teams running dozens of automations across n8n, Zapier or Make, built by several freelancers, where a few create invoices, orders or payments.
Connects to: n8n, Zapier, Make, Postgres, Slack, Google Sheets
The AI does: Very little, on purpose: where an AI step stays, it extracts or classifies under a strict schema, and code checks its output before anything is written.
People do: Decide which automations to keep, harden, move or delete, work the dead-letter queue, and approve any replay that would post money or reach a customer.
Built as: AI Workflow Automation, usually $3.5K - $12K

Seventy automations, three authors and no map

Take an online homeware retailer shipping a few thousand orders a month with an operations team of four. Over three years, three freelancers built its automations: about 40 Zaps, 25 workflows on a self-hosted n8n server, and a handful of Make scenarios. They move paid orders into accounting, create trade invoices, sync stock to a marketplace and post refunds. The operations lead calls it duct tape, and it works right up until the day it doesn't.

Nobody has the whole picture. Some Zaps still live in the first freelancer's own account, and the key that encrypts n8n's stored credentials sits in an environment file nobody has opened. Almost every run is green. Finance finds the problems at month end, when the accounting system is short eleven invoices for orders whose runs all say success.

That is the most common complaint about automation work once the build is paid for, and it is not about crashes, which are loud. The costly failures are quiet: a skipped branch, a retry that posted twice, an AI step that invented an ID. In August 2026, a builder on the n8n community forum described finding 27 branches skipped because their conditions could never match, while every run 'still finished as COMPLETED'.

The repair is rarely a rewrite. Most automations are harmless if they run twice or stop for a day. The handful that move money or change a system of record need what no platform gives by default: a record of what each run did, keys that make a retry safe, and a check that the destination really changed. The reasoning is in automation platform or owned integration layer; this page applies it to an estate someone else built.

Six ways a green run hides a failure

Each of these shows up as a success, or as nothing at all. None of the fixes depends on which platform the workflow runs on.

A retry that repeats the side effect

The API creates the invoice, the response is slow, and the platform times out and retries. A post on the n8n forum put it in one line: 'The API succeeded, n8n timed out, the retry fired, and the payment was posted twice.' Every side effect gets an idempotency key built from the source event, checked in a ledger before the write and sent to APIs that honor one, such as Stripe's Idempotency-Key header. Stripe may forget a key after 24 hours, so a replay next week relies on the ledger.

Half a run

Step two created the customer, step four failed, and nothing rolled back, because no platform can undo an external call that already succeeded. The ledger records each side effect with the ID it produced, so a replay resumes at the first unfinished step instead of creating a second customer.

A dead token that looks like an empty list

Google's refresh tokens expire after seven days for apps whose OAuth consent screen is still in testing mode, and a password change revokes tokens that carry Gmail scopes. The next run may simply read zero rows and finish green. Authentication failures become hard stops, a daily job exercises every credential, and OAuth apps move into the company's own tenants, published.

A branch that can never run

An IF node compares against a status the source system renamed, or a Zapier filter stops every run and Zap history files them as Filtered, not as errors. An n8n node that outputs no items quietly ends its branch, and Make documents that its Skip handler marks the run as a success even in case of errors. The ledger records each run's branch, and branches silent for 30 days go on a review list.

An API that changed underneath

Shopify ships an Admin API version every quarter and supports each for at least 12 months; a call to a retired version is answered by the oldest supported one rather than failing. Responses in money-moving flows are validated against a schema, so a changed field fails loudly, and pinned versions go into the inventory with their retirement dates.

Rate limits and vanishing webhooks

A bulk sync hits 429s and the platform drops records after its last retry. Worse, after eight consecutive failed deliveries Shopify deletes a webhook subscription created through the Admin API, and the workflow is never called again. Calls go through a queue that honors Retry-After, and an alert fires when a workflow's volume falls well below its usual level for that weekday.

What the audit does before anything is changed

The audit takes a week or two and changes nothing in production. The result is a document you own, useful even if someone else does the fixing.

Preserve the evidence. Self-hosted n8n deletes execution data after 14 days by default, so retention goes up and recent executions are copied out on day one.
Export every definition: n8n workflows as JSON (n8n export:workflow --all), Make scenarios as blueprints, and each Zap written up with its steps, filters and connected accounts.
Build the inventory: for each automation, its trigger, every system it writes to, whose account owns each credential, and its volume, error rate and branch history.
Sort by consequence, not complexity: would running it twice, or not at all, cost money, corrupt a record or reach a customer? Usually only a short list answers yes.
Switch on a read-only daily reconciliation for that short list, matching source events to the destination by reference. It turns suspicions into run IDs.
Read every error setting on the short list: n8n's retry and continue-on-error options, Make's error handlers, Zapier's filters and autoreplay.
Map credentials to people, including which API keys have no known owner and where the n8n encryption key is backed up.
Write it up as a ranked list: problem, evidence, consequence, fix and rough effort.

Everything after the audit is scoped from that list, one workflow at a time, and nothing is rebuilt that only needed a monitor.

Four verdicts for every automation in the inventory

Every automation ends up with one verdict. By count most land in the first row; by risk, the middle two carry nearly all of it.

Verdict	Which automations	What changes
Keep and monitor	Notifications, enrichment and reports, where a duplicate is invisible and a missed day survivable	An expected-volume alert and a runbook line. Nothing else changes.
Harden in place	Flows writing to a system of record at modest volume, where the platform is fine but a repeat is unsafe	Ledger rows, an idempotency check before each write, errors routed to the dead-letter queue, a reconciliation query.
Move to owned code	Anything that posts money, creates documents at volume, or hides critical logic in code steps	A small service with typed contracts, the ledger, backoff and replay. The platform can stay the trigger.
Delete	Output nobody reads, near-duplicates, experiments left switched on	Off for two weeks with the owner's sign-off, then removed.

The platform question comes last. Moving a Zap to n8n does not make it safe to run twice; the ledger and the key do.

One trade invoice, after hardening

Every money-moving workflow ends up with this shape, on n8n or in code. It has one model call, and nothing that call returns reaches the accounting system without passing a check written in code.

01 Trigger · Shopify webhook
A trade order is paid
Shopify sends the orders/paid webhook. Delivery is at least once, so the same order can arrive twice with the same X-Shopify-Webhook-Id.
02 Plain code · Postgres run ledger
Open a ledger row
The run records the webhook ID, the raw payload and an idempotency key built from the order ID and the action, create-invoice.
03 Decision
Has this key been seen before?
Checked inside a transaction, so two copies of one webhook cannot both pass.
- The key is completed then stop, log a blocked duplicate, write nothing
- The key failed part-way then resume at the first unfinished step, reusing IDs already created
- The key is new then continue
04 AI model · Structured output
Read the purchase order note
Trade customers type their PO number and cost center into the order note in any format. A small model extracts both under a strict JSON schema, with 'not found' allowed. It is never asked for an ID, an account code or an amount.
05 Plain code
Validate before writing
The PO must match the customer's known pattern, the contact ID comes from a lookup, and every SKU must exist in the catalog. Failures go to the dead-letter queue with the reason.
06 System · Accounting API
Create the invoice
Created through the accounting API with the order ID as its reference. Before retrying a timeout, code searches for that reference, because the first attempt may have worked; a 429 waits for Retry-After.
07 Decision
What actually came back?
Judged on the response body, not just the status code.
- An invoice ID then record it and mark the key completed
- A 401 or 403 then hard stop and alert; no retries until someone reconnects
- A 200 with an error inside the body, or a validation error then dead-letter queue, with the payload and the message
08 Person
Someone works the dead-letter queue
Failed items land in Slack with the reason, the payload and a runbook link. A person fixes the cause and presses replay, which reuses the same key, so it cannot post twice.
09 Result · Scheduled job
Reconciled every morning
A scheduled job matches yesterday's paid trade orders to invoices by reference and posts every difference to Slack.

Apart from the note extraction, all of this is ordinary code or configuration, and the ledger holds it together: it is how the system knows what it has already done.

The morning check, in its first week

Reconciliation goes live before any workflow is changed, because it turns suspicion into evidence. This is the kind of report it posts in week one.

Slack #ops-automation, Tuesday 06:00

reconcile(source: "shopify.orders_paid", target: "accounting.invoices", day: "2026-09-07", match_on: "reference")411 orders / 411 invoices / totals match / 1 order with no invoice / 1 order with two
ledger.runs(order: "58113")run 88412 / completed / no invoice ID recorded
execution(88412, step: "Create invoice")HTTP 200 / item-level error in the body: account code 4000 archived / run marked success
accounting.find(reference: "58140")INV-20930 from n8n run 88437 / INV-20931 from Zap 'B2B invoices v1', still switched on after the migration
dead_letter.add(order: "58113", reason: "error inside a 200 response")queued / replay blocked until the account mapping is fixed
Reconciliation report · Slack
7 September: totals match (411/411), references do not. Order 58113 has no invoice: the accounting API rejected it inside a 200 response (account code 4000 is archived) and the run was marked successful. It is in the dead-letter queue. Order 58140 was invoiced twice, once by the old Zap that is still on. Suggested: void INV-20931 and switch the Zap off. Runbook: B2B invoicing, sections 3 and 5.
Nothing was voided or replayed automatically. Both actions wait for a person.

The totals matched, which is exactly why the check compares references. A dashboard of 411 green runs would have hidden both problems.

The handover, from inherited to owned

A rescue that leaves the business dependent on its rescuer has only moved the problem, so the handover is part of the work.

Inherited

Zaps in a former freelancer's personal account
The n8n encryption key in an environment file on a server one person can reach
OAuth apps in someone else's Google Cloud project, still in testing mode
Workflows named 'Copy of Invoice flow (2) FINAL'
Failures discovered at month end, by finance

After the rescue

Every connection re-authorized from the business's own accounts, old keys revoked
Secrets in the business's vault, with the encryption key recorded and backed up
OAuth apps in the business's own Google and Microsoft tenants, published
A runbook per critical workflow: what it does, how to spot a failure, how to replay
Failures discovered the next morning, by a check, with run IDs attached

Do you need a rebuild, or a monitor on what you already have?

Often you need neither a rebuild nor a new platform. If your automations mostly notify, enrich and report, keep them, switch on n8n's error workflow and Zapier's and Make's failure notifications, and add an expected-volume alert per workflow. Know the limit: n8n's error workflow fires only when an execution fails, so it never catches a run that succeeded at doing nothing. With no money-moving flows, that is enough, and I would tell you so.

Build when an automation moves money or changes a system of record and nobody can answer 'did this run, and what did it do?' without a vendor's execution log. The fix is then an owned layer (ledger, idempotency keys, typed contracts, replay), as a small service or around n8n on your own server. A move from Zapier to n8n can make sense for cost at volume or EU self-hosting, as the n8n, Zapier and Make comparison explains, but on its own it copies the fragility to a new canvas.

The usual end state is a split: low-stakes flows stay on the platform, where operations can edit them, and the few money-moving ones get the ledger and reconciliation, often with the platform still as the trigger. Migrated flows run side by side with the old ones until the two reconcile. It is the least glamorous kind of AI workflow automation, and usually the first worth doing.

How you would know it is working

A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.

Reconciliation gaps: Source events with no matching destination record, or with two, counted by reference rather than totals. The target is zero, held for weeks.
Duplicates blocked: Runs stopped by the idempotency check. Nothing was harmed, but a rising count points at a retry or webhook problem upstream.
Time from failure to detection: From the failed event to the alert or morning check that surfaced it. The goal is the next morning, not month end.
Dead-letter queue age: How long items wait for a fix and a replay. Old items usually mean the alerts reach the wrong person.
Branches that never fire: Branches with no runs in 30 days, listed monthly: dead logic to delete, or a condition that can no longer match.

What a build like this costs

This is built as AI Workflow Automation, which runs $3.5K - $60K overall. A build like this one usually lands in the single-step flow tier: $3.5K - $12K, 1-2 weeks. The first working version runs on your real data well before the end of that window.

What it costs to run

The additions are small: a Postgres database and a few scheduled jobs, on the server that already runs n8n or a managed database for tens of euros a month. Remaining AI steps cost cents per run, and the ledger stops a retry from paying twice for the same call. If model spend is the real worry, that is an AI cost audit.

What moves the price

The number of automations, platforms and accounts, and how many write to a system of record
Whether execution history survives, or the evidence must be rebuilt from the destination systems
How many flows move money or create documents, since each gets a ledger, idempotency and a reconciliation query
Credential cleanup: re-authorizing connections, registering OAuth apps, rotating keys with no known owner
Whether flows move into owned code, or from Zapier or Make to self-hosted n8n

Who this is for

Retailers and wholesalers whose orders, invoices and refunds run through Zapier, Make or n8n workflows nobody fully understands
Agencies that built automations for clients and now field the support calls
Teams whose automation freelancer left without handing over accounts, credentials or documentation
Operations leads moving from Zapier or Make to n8n who want the risky flows fixed, not copied
Finance teams finding missing or doubled records at month end, with every run marked successful

Questions people ask about this

Why does my n8n workflow say success when it did nothing?

Because nothing failed in a way n8n counts as failure. A node that outputs no items ends its branch quietly, an IF condition that can no longer match skips the work, and a node set to continue on error passes an empty result along. The run is marked successful and the error workflow never fires. Check outcomes instead: volume alerts and a daily reconciliation against the destination.

How do I stop Zapier or n8n from creating duplicates when a step retries?

Give every side effect an idempotency key built from the source event, such as the order ID plus the action, and check it in a ledger before writing. Pass it to APIs that accept one, like Stripe. Where an API does not, search the destination for that reference first, because the timed-out attempt may have succeeded. Replays reuse the key, so they cannot post twice.

Can AI agents be trusted to write to our CRM or accounting system?

Not directly. Agents invent IDs and fields when inputs are empty or ambiguous, and a confident wrong value is worse than a failed run, because nobody notices it. Let the model extract or classify under a strict schema, with 'not found' allowed, and let code look up IDs and validate every value before the write. The model picks among options; it never types an identifier.

Should we migrate from Zapier to n8n?

Sometimes: for cost at volume, for EU self-hosting, or for code Zapier's steps cannot run. But a migration copies the same fragility to a new platform unless the risky flows are fixed on the way. I would audit first, harden the money-moving flows, then move the rest one at a time, running old and new side by side until their outputs reconcile.

How much does an automation audit cost?

The audit is a small, fixed piece of work sized by the number of automations, platforms and accounts, and it ends with a ranked list you keep whether or not I do the fixes. Hardening is then scoped per workflow. The typical range for this work is shown on this page, and a free 30-minute call is usually enough to size the audit.

Sources