It broke and it didn't tell anyone

The gap between ran and worked

Make, Zapier and n8n all do what they're told. That's the problem.

A scenario runs. It calls an API. The API returns a 404 because a field name changed last Tuesday. The module receives a response, which is what it was waiting for, and moves on. The run completes. The dashboard shows green.

Nothing in that sequence is a bug. The tool did exactly what it was configured to do. What's missing is anybody having decided what should happen when the response isn't the one you expected, and that decision is not made for you by default.

Six ways it happens, named

Silent HTTP failures. A call returns 4xx or 5xx and the workflow treats a response as success. The fix is checking the status code explicitly and routing anything that isn't a 2xx down an error path.

Partial writes. The automation updates three systems. The second one fails. The first is now ahead of the third, and nobody knows. This is the most expensive failure on the list because it produces data that looks fine and isn't. Any workflow that writes to more than one place needs to know what to do when it gets halfway.

Rate limits consumed quietly. Most APIs return a 429 and expect you to back off. Without a retry with exponential backoff, the run drops the record and continues. Volume grows, the limit is hit more often, and the failure rate rises slowly enough that nobody notices a trend.

Expired credentials. OAuth tokens expire, API keys get rotated, a service account gets removed when somebody leaves. Every one of these produces an authentication error that a workflow without an error branch treats as an ordinary response.

Changed field names. Somebody renames a column in a spreadsheet or a field in a CRM. The automation maps to the old name, gets nothing, and writes an empty value. Empty is a valid value, so nothing complains.

Ordering assumptions. The workflow assumes the confirmation email arrives before the payment webhook. At low volume it always does. At higher volume it sometimes doesn't, and the failure looks random, which makes it hard to reproduce and easy to dismiss.

What a rebuilt version has that the original didn't

An explicit error path on every external call. Not a global handler. Each call knows what a bad response looks like and what to do about it.

Retries with backoff, and a limit. Transient failures should be retried. Permanent ones shouldn't be retried forever, because a retry storm against a broken endpoint is its own outage.

Idempotency. If the same record gets processed twice, the second run must not duplicate the work. Usually this means a key on the record and a check before writing.

A log of what it actually did, not just that it ran. Which records, which outcome, which errors. You want to be able to answer "what happened to order 4471" without reading a scenario diagram.

An alert that reaches a person. Not an email to an address nobody watches. Something that appears where somebody will see it within the hour, with enough detail to know whether it matters.

A dead letter queue, or the equivalent. Records that failed and were not recovered go somewhere visible, so the pile is countable rather than invisible.

How to check your own

Three things, in order.

Find the last run that failed and see whether anybody knew. If the answer is that you found out from a customer, the alerting isn't there.

Take one external call and break it deliberately. Change a credential to something invalid and run it. Watch what the workflow does. If it completes, you have a silent failure path.

Count how many records went through last month, and compare that to how many should have. A gap you can't explain is the automation losing work quietly, which is the normal case rather than the exception.

None of this is an argument against the tools

Make, Zapier and n8n are good, and for a lot of processes they're the right answer. Every one of the fixes above can be built in all three.

The difference isn't the tool. It's whether somebody sat down and decided what should happen when things go wrong, which takes about as long as building the happy path did, and is the part that almost nobody does when they're building it themselves between other jobs.