Automations That Don't Break at Scale

Zapier and Make are great until they aren't. Patterns for building automations that survive growth.

Most automation stacks work fine at 10 records a day. The problems show up at 500. Not because the tools can't handle the volume — they usually can — but because nobody designed for failure, documented the logic, or tested against real-world edge cases.

Automations that break at scale almost always broke quietly first. A missing record here, a skipped email there. By the time the failure is visible, it's been accumulating for weeks.

These are the five principles I apply to every automation before it touches production data — whether it's a five-step Zapier workflow or a complex Make scenario.

The five principles

Treat automations like code: name them, version them, document them

The fastest way to break an automation is to hand it to a second person with no documentation. Every automation should have a name that describes what it does ("New Lead → HubSpot + Slack Alert"), a note explaining why it exists, and a record of the last time it was tested. Treat it like a function in a codebase.

One automation, one job

The most brittle automations are the ones that do five things in sequence. When step 3 fails, you don't know if steps 4 and 5 ran. Split multi-step workflows into separate automations with a clear handoff between them. If one breaks, you know exactly where and can fix it without touching the rest.

Always handle the failure case

Zapier will send you an email when a zap fails. Make will log it. Neither does anything useful with the failure by default. For any automation that moves money, creates records, or sends emails to customers, build an explicit failure path: a Slack alert, a fallback record, a retry. Silence on failure is the worst outcome.

Use filters early, not late

Every unnecessary automation run costs money and adds latency. If your zap should only fire when a form submission has a specific tag, filter for that tag at step 1 — not step 6 after you've already hit four APIs. Filters at the start of an automation keep task counts low and failure surfaces small.

Test with real data, not sample data

Zapier's sample data is sanitized. Real records have edge cases: empty fields, unusual characters, emails with plus signs, names with apostrophes. Build your automations against a copy of real data before putting them in production. The ones that break on sample data are obvious; the ones that break on edge cases are expensive.

The audit question no one asks

Every quarter, pull your automation task history and look for the ones running most often. Then ask: is this automation still necessary, or is it compensating for a process problem?

The most expensive automations are often the ones solving problems that could be eliminated upstream. A zap that fires 10,000 times a month to clean up bad data might mean your form needs a validation rule, not a downstream cleaner.

Patterns that hold up at scale

Webhook → Queue → Action

Make or n8n

Instead of triggering an action directly from a webhook, push the event to a queue first. This decouples the trigger from the action, lets you replay failures, and prevents overloading a downstream API during traffic spikes.

Deduplication before write

Airtable formula or Supabase upsert

Before creating a new record, always check if it exists. Zapier's "Find or Create" step exists for this reason. Without deduplication, any automation that triggers on form submissions will eventually create duplicate records — guaranteed.

Rate-limit-aware batching

Make (iterator + aggregator)

APIs have rate limits. When sending 500 emails or updating 500 CRM records, batch them in groups of 10 with a delay between batches. Make's iterator and aggregator modules handle this natively. Zapier requires a workaround with delay steps.

Error logging to a dedicated table

Airtable or Google Sheets

Add an error path to every mission-critical automation that writes the failure reason, timestamp, and record ID to a dedicated error log. This gives you visibility into what broke, when, and what data was affected — without relying on email notifications you'll miss.

When to move off Zapier to Make or n8n

Zapier is the easiest entry point. It is not always the right long-term choice.

Task volume > 5,000/month

Then

Move to Make. Same visual editor, dramatically cheaper per task, better error handling.

Complex branching logic

Then

Make handles conditional routing far better than Zapier's linear flow. n8n is better still for complex graphs.

Self-hosted requirement

Then

n8n is open source and self-hostable. If your data can't touch third-party servers, n8n is the answer.

Prompts to audit your automations

Use these to get a structured review of your current workflows.

Automation audit Copy & paste

I have the following automations running: [describe each]. For each one, identify: (1) single points of failure, (2) missing error handling, (3) steps that could be eliminated, and (4) whether it should be split into smaller automations.

Cost reduction Copy & paste

My Zapier bill is $[X]/month and I'm running [N] zaps with [M] tasks/month. Which automations are most likely to be candidates for consolidation or migration to Make to reduce cost?

Scale readiness Copy & paste

I expect my [describe workflow] automation to go from 100 runs/month to 5,000 runs/month in the next 90 days. What will break first, and what should I change now to prepare?

Playbook · Weekly

More guides like this, every week

Automation patterns, stack decisions, and tool guides for founders building without engineers.

Tap in →