n8n, Make and Zapier Builds With a Failure Path

The tool choice is not decided by price per task. It is decided by what happens at 02:00 when a step fails. Zapier retries a few times and then stops, and unless somebody reads the email the record is gone. That is acceptable for a notification and unacceptable for a lead handoff to a dealer. So the first thing I build in any of these platforms is the failure path, and the second is the way you find out. Choosing between them honestly: Zapier for low-volume work across many applications, where an outage costs little and nobody wants to operate anything. Make when the shape of the work is loops, aggregation and branching, since the iterator and aggregator pair does in one scenario what takes a dozen Zaps, and when the visual run history matters to a non-technical owner. n8n when volume, data residency or transformation logic makes hosted per-task pricing absurd, and when somebody can own a service. n8n in queue mode with Redis and two workers on a small VPS runs around forty dollars a month and absorbs volumes that price Zapier in the thousands. It is also a service you now operate, with upgrades and a backup policy, and I say that out loud before you choose it. What every build gets: Idempotency, so a webhook delivered twice does not create two records. A dedupe store, whether a Postgres table, a Make data store or an n8n static key, keyed on the source system's own identifier rather than on a timestamp. Signature verification on inbound webhooks where the sender offers it, and IP allow-listing where it does not. Retries with backoff, then a dead letter destination a human actually sees: a table plus a message carrying the payload and the failure reason, not a generic alert nobody opens twice. Then a run log. Every execution writes id, source, outcome and duration somewhere queryable, because the question you will ask in month three is whether one specific record got through, and no platform's native history answers that past its retention window. Migrations off Zapier: The mistake is a like-for-like port. Multi-step Zaps often encode workarounds for Zapier's own constraints that stop making sense in n8n, and rebuilding them faithfully carries the workaround forward. I map the intent of each Zap rather than its steps, and the count typically drops by a third. Old and new run in parallel with outputs compared before anything is switched off. What I will not put in a no-code automation: Money movement, KYC or policy issuance for a regulated client. Those belong in code with tests and an audit trail, and I will tell you so even though it makes for a smaller invoice. I also will not build the single scenario that does eleven things, because when it breaks at step seven you recover by hand. And I do not take on automations whose specification is a photograph of somebody's whiteboard; writing the specification is part of the work and we do it together. Not for you if: You want the cheapest build. Error handling, logging and a replay path add roughly a third to the work, and the whole of that difference shows up on the bad day. If nothing you are automating matters enough to justify it, use Zapier's own templates and spend the money elsewhere. I mean that as advice, not as a negotiating position. Handover: n8n workflows exported to a git repository with credentials referenced rather than embedded. A one-page runbook per workflow: what it does, what breaks it, how to replay a failed run. Access to the log table and the alert channel. Then you own it.