Why your Zapier chain breaks at 2am, and what to do instead

Every business I work with has a Zap somewhere. A form submission creates a contact. A new order posts to Slack. A row lands in a sheet. These are good. They take ten minutes to set up and they get a job off someone’s plate.

The trouble starts when one of them quietly becomes the way money moves. The order-to-invoice Zap. The one that updates stock. The one with six steps, two filters and a formatter in the middle that nobody remembers configuring. When that one fails at 2am, nothing tells you. You find out when a customer asks where their order is.

How you know it’s load-bearing

A rough test. If any of these are true, the automation has outgrown the tool it lives in:

1. It touches money, stock, or a customer-facing status.
2. It runs more than a few hundred times a month, and the bill now has its own line in the budget.
3. Data flows in both directions, so a retry can create a duplicate.
4. Nobody can explain, from memory, what every step does.

What the boring replacement looks like

Not a platform. A small service, a few hundred lines of code, that does the one job. It receives the webhook, puts it on a queue, processes it, and writes a log line you can read. If the API on the other side is down, it waits and tries again. If it fails three times, it tells a human. If the same event arrives twice, it notices and does nothing.

That log is the whole point. When something looks wrong, you or I can read it and know what happened, in order, with timestamps. A Zap history page tells you a step “errored”. A log tells you why.

When to keep Zapier

For one-way, low-volume, low-stakes pushes, keep it. A new lead posting to a channel does not need a queue. The point isn’t that no-code is bad. It’s that the tool should match the stakes, and the stakes tend to creep up without anyone deciding they should.

If you’ve got a chain you’re a little nervous about, send me a screenshot of it. I’ll tell you honestly whether it’s fine where it is.