Make.com 429 Rate Limit Fix: Circuit Breaker Protocol

TL;DR

Make.com 429s come from three different layers

Engineers call all of them "the Make rate limit error" and then chase the wrong fix. The three layers behave differently, and the message rarely tells you which one fired.

The first layer is Make's own API. Every request you send to Make — organization calls, admin automation, anything hitting api.make.com — is counted against your plan's organization limit. Hit it and the response is a 429 with a specific sentence about your organization.

The second layer lives in the connected app. Google Sheets, Airtable, OpenAI, Slack — each has its own quota, and Make's error text usually names the provider or uses wording like "too many requests". Make counts nothing here. Your plan has no bearing on it, and upgrading Make will not help.

The third layer is your own design. Instant triggers fire per event, iterators fan a bundle into hundreds of operations, and pagination loops run until a page is empty. Total daily volume can look modest while a single ten-second window spikes past a limit nobody is measuring.

Make's HTTP handling draws the boundary for you: any response in the 400–599 range is treated as an error, and a rate-limit response is classified as one that the platform retries on its own. Everything below assumes that default. The question is what happens around it.

If your 429s are landing on the cost side instead — overage bills rather than hard failures — the operation math is a different article, and we walked it through in the Make.com overage pricing breakdown.

The three layers, side by side

Read the failing module first. If the error text mentions your organization, you are in layer one and the scenario is almost never the cause. If it names Sheets, Airtable, or a model provider, you are in layer two and the fix is pacing. If the failing module is your own HTTP call and the same app fails from several scenarios at once, you built layer three.

The org API numbers Make publishes

Make documents its organization API limits by plan. These are requests per minute against the Make API, not operations inside scenarios.

Exceed the limit and you get error 429 with the message Requests limit for organization exceeded, please try again later.

You can read your own ceiling instead of guessing it. Call GET {base-url}/organizations/{organizationId} and the license object in the response carries an apiLimit property with your organization's rate limit. Pull that once, store it, and your monitoring can compare it to observed traffic rather than to a number from a blog post.

Keep the two ceilings separate in your head. The organization limit governs calls into Make. The app limits behind your modules govern calls out. A 429 on the second layer is invisible to the first, which is why a plan upgrade so often changes nothing.

What Make already retries for you

This is the part most teams rebuild by hand when they do not need to. Make's behaviour on a rate-limit error with no error handler attached depends on two switches: whether the scenario is scheduled or instant, and whether incomplete executions are enabled.

The single most valuable setting here is Store incomplete executions in Scenario settings, and it ships disabled. Turn it on and a failed run is kept with its input data instead of vanishing. Leave it off and a 429 can cost you the bundle, permanently. Instant scenarios retry either way, but "retry" only means something if the data still exists.

The automatic backoff schedule, in full

Rate limit, connection, and module-timeout errors get retried automatically. The schedule is fixed, and it is longer than most people assume.

Eight attempts, spread over almost eight hours. Two limits shape how that behaves in practice. Make runs a maximum of three incomplete-execution retries in parallel per scenario, batching the rest as the previous batch finishes, so a backlog of fifty failures drains slowly. And a retry will not start while the original scenario is already running.

The same page also covers the Retry error handler when you enable automatic run completion: the default is 3 attempts at 15-minute intervals, and both numbers are adjustable.

The five error handler directives in 2026

Make's current documentation names five directives: Skip, Retry, Resume, Commit, and Rollback. Older tutorials use the retired names Ignore and Break, so match your reading to what the builder shows you today.

The directive decides what the platform does with the failure. Getting it wrong is worse than having no handler, because a handler that swallows a 429 quietly converts a visible outage into missing records.

• Retry — stores the incomplete execution and enables automatic or manual retries. This is the default choice for a 429, a connection error, or a timeout, because those usually clear on their own. It pairs with the backoff table above.
• Resume — supplies a substitute value and lets the scenario continue as if nothing failed. Use it when the step is optional, such as an enrichment call whose absence is survivable. Use it on a write step and you will skip records silently.
• Skip — discards the error and moves on to the next bundle. Acceptable for analytics writes and logging, wrong for anything that creates or updates a business record.
• Commit — stops the run on the error but keeps the changes already made. This is for an intentional stop on a business rule, not for rate limits.
• Rollback — stops the run and reverts what earlier modules changed, where they support it. The correct choice when a half-created order is worse than no order.

Map the directive to the status, not to the mood of the moment. A 429 wants Retry. A persistent 4xx wants Skip or Rollback plus an alert, because retrying bad data just fails again more slowly. A 5xx wants the circuit breaker below.

Rate limit headroom calculator

Plan limits mean nothing without your own traffic next to them. Enter your ceiling and your peak, and see how much room you actually have.

A circuit breaker you can build in four modules

The automatic backoff handles a blip. It does not handle a service that is down for two hours. In that case every scheduled run fires, fails, gets stored, and consumes operations while nothing succeeds. A circuit breaker cuts that off at the source.

The shape is four pieces, and you can build it with the modules you already have.

1. A Data Store key as the breaker state. One key, something like svc_openai_down, holding a timestamp and a boolean. Make's Data Store gives you a place to keep it between runs.
2. A check before the request. First module of the branch: read the key. Filter on it. If the flag is set and not expired, skip the call and route the bundle to a queue or a log instead of firing a doomed request.
3. A set-on-failure path. Wire the failing module's Retry handler so that its final failure also writes svc_openai_down = true with a 10-minute expiry. Ten minutes is a starting value; match it to how long the provider's own incidents usually last.
4. A health check that clears it. A small scheduled scenario (once every five or ten minutes) makes one cheap call to the provider. Success clears the flag and traffic resumes; failure extends it. The breaker closes itself.

The breaker is worth building because it changes the cost model, not just the error rate. During a two-hour outage, an unbroken scenario with a one-minute schedule attempts 120 runs, each spending operations on a call that fails identically. With the flag set, most of those runs skip the call entirely. You trade a small amount of latency for a large cut in wasted operations — the same logic our Make vs Zapier cost analysis applies at the execution level, and the hybrid orchestration blueprint shows where a self-hosted worker cluster takes over when a managed ceiling becomes the bottleneck.

If you would rather not run a breaker at all, the honest alternative is the self-hosted route: a queue-mode worker cluster absorbs bursts without a per-minute org ceiling. We documented that path in the n8n queue mode setup.

The controls that actually move the 429 rate

Five controls do the work. Reach for them in this order.

• Scenario rate limit (instant triggers). The Maximum runs to start per minute field, found behind the lightning icon on the instant trigger module, spreads an event spike over a longer window. This is the single highest-impact setting for a webhook-driven scenario.
• Records per run (scheduled triggers). Lengthen the interval or lower the per-run limit. Make's own guidance recommends up to 20 records per run when you need frequent runs — for example, run every minute and process 20 rows.
• Bulk and aggregator modules. One bulk write of 20 rows costs one request where 20 single writes cost twenty. Aggregators collapse several bundles into one. Both cut the numerator of the rate equation instead of slowing the whole scenario down.
• Sleep, used sparingly. The Sleep module delays a request by up to 300 seconds. Make's own example: an app limited to 10 requests per minute wants a 6-second delay. It is a scalpel, not a strategy — Make notes that Sleep often postpones the problem rather than solving it, and at batch scale the runtime cost gets ugly fast.
• Process data in order, with eyes open. It makes the trigger handle bundles one at a time instead of in parallel, which smooths bursts. The documented catch: it stops the scenario in the event of errors, and when incomplete executions are enabled the scenario pauses until they are processed so the order is preserved. For a 429-heavy workflow that is a trade, not a free win.

One rule ties them together: an app counts its requests against the rate limit across every scenario that uses it. If three scenarios all call the same app, they share one envelope. Two individually "safe" scenarios can trip a 429 together, and neither one looks guilty in isolation. Check the app across your whole workspace before you blame a single scenario.

Failure modes we have hit

1. Retrying a provider that is down. A scenario with a Retry handler kept firing at a dead API for two hours and burned a month of operations on identical failures. The breaker exists because of this one.
2. Incomplete executions left off. The default. The scenario retried on schedule, but the bundle was gone, so "retry" retried nothing. Turn the setting on before you need it, not after.
3. Blaming Make for a third-party limit. The error named the app, the team upgraded the Make plan, and nothing changed. The limit was the provider's, and the provider did not care about the invoice.
4. Two scenarios, one shared envelope. Each was tuned to half the app's limit. Together they exceeded it. The fix was a shared Data Store counter, not more spacing.
5. Sleep everywhere. Fifty records at a two-second delay turned a forty-second job into a sixteen-minute one, and the 429s continued because the peak was the problem, not the average.

When to raise the plan instead of engineering around it

Engineering around a limit is worth it when the burst is yours and the ceiling is Make's. A scenario rate limit plus batching fixes that class permanently, and it is free.

Raise the plan when layer one is genuinely saturated and the traffic is legitimate — Core's 60 requests per minute is a low ceiling for an admin-heavy workspace, and jumping to Pro at 120 or Teams at 240 is cheaper than the engineer hours you would spend pacing around it.

And when the bottleneck is a third-party app's limit that no plan change touches, neither lever helps. The answer is either a queue that smooths demand against a provider that cannot absorb it, or a different provider. That decision is about architecture, and it is worth making explicitly rather than arriving at it one 429 at a time.

Ship the breaker before you need it

Rate-limit failures are boring right up to the moment a provider goes down and your workspace spends the afternoon failing. The cheap sequence: enable Store incomplete executions today, confirm your org apiLimit so you are measuring against a real number, cap instant triggers with the runs-per-minute field, and add the Data Store breaker to the one or two modules that call a third party you cannot survive without. That is an afternoon of work that pays for itself on the first outage.

FAQ

Related Cluster Intelligence

• Voiceflow vs Bland.ai: Voice Agent Comparison →
• ElevenLabs Pricing 2026: Plans, Credits, Alternatives →
• ActiveCampaign vs HubSpot: Cost at Your Contact Count →
• Hetzner vs DigitalOcean vs AWS for n8n Docker →
• n8n Queue Mode Docker Compose & Redis Setup →
• n8n Postgres vs SQLite: The Queue Mode Benchmark →