When the other app says slow down, what happens to the records

September 2, 202618 min readUpdated September 13, 2026

A flow that has run for two years begins taking three times as long to finish. Nothing shows as broken. Somebody eventually goes digging and finds the reason buried in the run detail: rate limit exceeded, try again in a few hundred seconds. It can take a month to notice that an automation has slowed to a crawl because too many requests were going out, because a slow success looks exactly like a success.

That is what it looks like when your automation stopped syncing because too many requests went out at once. No error anybody reads, and nothing on the screen that says the other end is the one saying no.

Your automation is doing exactly what it was told, and the app on the other end has started refusing the calls. Shopify, Gmail, QuickBooks or a booking system decides you are calling too often, refuses the call, and your records either wait somewhere or drop out of the day. Which of the two happens is the half nobody writes about.

Three things are worth knowing before it happens: which of your apps has a ceiling low enough to matter, and what your platform does when it hits one. The third is the setting that decides whether the skipped records come back by themselves.

Who does this actually happen to?

On most days, nobody. Push a handful of orders, invoices or bookings an hour and you will never come near these ceilings. They bite on particular days: a bulk import, the first sync between two systems, a mail-out to the whole list, the Saturday after an ad ran.

So it is a burst problem before a volume problem. The ceilings are written per second or minute, and an ordinary Tuesday never fills one. An afternoon of catching up will.

When the same automation hits the same ceiling every week, ask whether that work should run this way at all. That is one of the tests in when not to automate a process.

My automation stopped syncing and the error says too many requests. What is that?

It is a refusal, and it comes from one of two places. Either the app on the other end turned your call away, or your automation platform held you back itself. Zapier states the split in its own words: "Zapier rate limits and app rate limits are separate. Zapier controls how often your Zap workflows can run, while each third-party app enforces its own API limits." An API is the doorway one program uses to talk to another, and the ceiling sits on the doorway rather than on your workflow.

The same page tells you how to read which one you have: "To differentiate between an app error and a Zapier error, look for 'Zapier' in the error message."

Most of these ceilings are a burst allowance that refills at a fixed rate, so a short spike is forgiven and a sustained one is not. The allowance is shared, which is what surprises owners. Zapier again: "An app's rate limit is shared across all Zap workflows in your account." Shopify says the same from its end: rate limits "are based on the combination of the app and store". One budget per connection, split across everything built on it.

Which of your apps has a ceiling low enough to matter?

Four of the usual suspects, and they count in four different ways. Shopify counts a points budget rather than calls. Gmail counts the mailbox separately from the connection. QuickBooks counts per company file. Calendly counts per user, and its booking ceiling is the lowest here.

App	Documented limit, read August 2026	In plain terms
Shopify GraphQL Admin API	"100 points/second" standard, 200 Advanced, 1000 Plus	A points budget, not a count of calls
Shopify REST Admin API (legacy)	"Bucket size: 40 requests/app/store", "Leak rate: 2/second"; ten times on Plus	Two a second steady, burst of 40
Gmail API	"6,000 quota units" per minute per user per project; "messages.send - 100"	About 60 sends a minute, my arithmetic
Gmail sending (the mailbox)	"2,000" a day per user; "500 for trial accounts"	The mailbox stops sending
QuickBooks Online	"500 requests per minute, per realm ID and app. 10 concurrent requests in one second"	One company file, 500 a minute, 10 at once
Calendly	"Paid Plans - 500 requests per user per minute"; "Free Plan - 50"	Per user, shared with your integrations
Calendly, Create Event Invitee	"Paid, Non-Enterprise - 10 per minute / 50 per hour / 100 per day"	Reachable in one afternoon

The Gmail row needs care. Google does not count calls, it counts quota units

a price in points that each kind of request costs. The published ceiling is 6,000 units a minute, and a single send is priced at 100. Sixty a minute is my division of one number into the other, which Google states nowhere.

Shopify's Plus figures are ten times the standard ones, so the tier matters whenever somebody quotes a Shopify number. And the published ceiling is not the only one: order creation has its own, lower limit, and an app spacing its calls a second apart can still be refused after a handful of orders. 429 is the number an app sends back when it means "too many requests, slow down".

Calendly is the row to check if you take bookings. Its limits "apply to both direct API calls and calls made through third-party integrations", and are "enforced per user". Load a term of classes into a studio's calendar and you pass 100 invitees before lunch.

The QuickBooks figures come from an Intuit support-centre article dated 14 November 2024, not the API reference. "Realm ID" means one company file, so 500 a minute covers a whole set of books.

All of this was read in August 2026, and it moves. Google's quota page says its limits changed on 1 May 2026, and Workspace is blunter: "Sending limits can change without notice." Check the vendor's page.

If you would rather have somebody work out which of your connections sits close to a ceiling, that is part of what the process audit produces in writing. It costs $299, takes three business days, and the map is yours whether or not you hire us.

Does the app itself hold your record while it waits?

Shopify answers this in one sentence on its older REST documentation, and the answer is no. "The throttle is a pass or fail operation. If there is available capacity in your bucket, then the request is executed without queueing or processing delays. Otherwise, the request is throttled." Shopify parks nothing for later. If the record survives, it survives because your platform kept it.

It does say when to come back: a refusal returns "a 429 Too Many Requests error and a Retry-After header". The header is a number of seconds bolted onto the refusal, saying when to try again. Whether anything acts on that number is your platform's business.

Gmail adds a wrinkle. Once a user is over quota, "there can be a delay of several minutes before the API begins returning 429 error responses". Then the line that matters most: "You can't assume that a 200 response means the email was successfully sent." Google says that about Gmail, and I would not stretch it to another vendor without their own sentence.

The door then stays shut a while. Daily limits exceeded "might result in these errors for multiple hours", and "Per-user limits cannot be increased for any reason."

A run that finishes green while the record never arrived belongs to why automations fail silently.

Zapier: held, errored, and only one of them waits for you

Zapier splits this in two, and the split decides whether a person presses anything. Where Zapier holds you back, runs go to an on hold status and wait. Where a connected app refuses the call, the run errors and stops. Held runs need a human. Errored runs are retried automatically, if autoreplay was switched on.

Every cause Zapier lists for a held run is a Zapier-side one: too much data arriving at once, a disconnected app, the step limit. A connected app's own refusal is not on the list.

The one that catches busy days is flood protection, and it applies to only one of the two ways a Zap can start. A polling trigger is Zapier going off to look every few minutes; an instant trigger is the other app pushing the event across the moment it happens. "For Zap workflows that use polling triggers, if you have 100+ events that trigger a Zap at once, Zapier will hold them for you. Flood protection counts all incoming trigger items before any Filter or Path steps run."

Two things follow. A filter discarding 90 of your 100 records does not save you: the counting comes first. And "Instant triggers are not subject to flood protection", so your exposure depends on how somebody built the connection.

Zapier then emails you "requesting you to confirm these actions should run", after which "Zapier processes these replayed Zap runs at a rate of 1 per second. For example, 1,000 Zap runs will take a little over 15 minutes to complete." The clock starts when somebody presses the button, and the button is yours.

Autoreplay does not cover held runs: "Autoreplay will not replay Zap runs with an on hold status... Manually replaying on hold runs requires a paid plan." On the free plan, manual replay covers errored runs only.

Where it does apply, the schedule is published. Errored steps are replayed "up to 5 times", at 5 minutes, then 30 minutes, 1 hour, 3 hours and 6 hours. The last falls "about 10 hours, 35 minutes after the first error". Zapier also "will not send any error notification emails until the final autoreplay attempt fails", so a throttled Saturday can finish its whole cycle before your inbox hears about it. Manual replay has a 60-day deadline.

You can raise the flood protection ceiling in the Zap editor, to "a maximum limit of 1,500 events at once". Zapier warns that "You may still experience rate limiting directly from the app even after you adjust the flood protection limit in Zapier." Raising your own ceiling does nothing about Shopify's.

Make retries eight times, if you turned on the part that keeps the record

Make retries a rate limit error by itself, on a published schedule of eight attempts. Whether anything survives for you to look at afterwards comes down to one checkbox in scenario settings, and it ships off. Incomplete executions guard against "data loss that could happen", and they "are disabled by default."

With the checkbox on, Make "automatically retries incomplete executions that have been created because of: RateLimitError, ConnectionError, ModuleTimeoutError". The gaps run 1 minute, then 10, 10, 30, 30, 30, and two of 3 hours. The eighth and last attempt lands 7 hours 51 minutes after the original run.

With the checkbox off, the retries stretch instead: 1 minute, 2, 5, 10, then an hour, 3 hours, 12 hours and 24 hours. The last lands roughly forty hours out, and nothing is stored to retry by hand. Either way there is a hard stop: "If the 8th attempt fails, Make disables scheduling of the scenario."

The manual retry has a trap. "You can retry incomplete executions only when the scenario is active." Repeated errors are what switch a scenario off, so Monday morning is often the one state where Retry does nothing. Turn the scenario on first.

No bulk fix exists without the storage either. A volunteer holding Make's Community Champion badge told somebody with several hundred incomplete executions that they would "have to manually run them individually".

One more thing decides your fate, invisible from outside. Make's developer documentation says a 429 is handled "as a RateLimitError by default", which lets the scenario retry. A plainer error "counts toward the scenario's consecutive-error limit (3 by default)", after which scheduling switches off until a human turns it on. So the outcome can come down to how somebody labelled an error inside a connector you never see.

Power Automate slows the flow, then turns it off

Microsoft documents no queue of held records anywhere I could find. It documents a flow slowed, an action retried, and a flow switched off if the throttling never stops. The throttling in question here is a connector refusing you, which is a different cause from your own subscription running out. Microsoft treats both the same way on the limits page: "Flows that violate them can be throttled, or slowed down, or even turned off altogether if they're throttled continuously for 14 days."

Retries are on by default, and the policy follows the performance profile. Low "sends up to two retries", scaling "up to an interval of approximately 10 minutes for the last retry". Medium and High send "up to 12 retries", out to "approximately 1 hour for the last retry".

Runs are kept 30 days, your window to resubmit one. Microsoft warns where the ceiling usually sits: "Individual connectors have their own limits, which you often reach before the limits mentioned previously."

What it feels like is in the Azure Logic Apps documentation, which covers the engine underneath rather than Power Automate itself. "Throttling can create problems such as delayed data processing, reduced performance speed, and errors such as exceeding the specified retry policy." Delayed data processing is what the owner in that Power Platform thread spent a month not noticing.

So where does the queue live, and who presses the button?

In three different places, and only one of them is on by default. Zapier keeps held runs in Zap history. Make keeps failed ones only if you switched the storage on. Power Automate keeps runs rather than records. The recovery half sits below, side by side. The row that decides your Monday is the fourth.

	Zapier	Make	Power Automate
Holds the record?	Yes for Zapier-side limits, as an on hold run. No for a connected app's refusal, which errors and stops.	Only when "Store incomplete executions" is on, and it ships off.	Not documented. The action retries; the run sits in history.
Retries on its own?	Only with autoreplay on, and only errored runs.	Yes, for a rate limit error.	Yes, on every action by default.
Schedule	5 attempts, the last "about 10 hours, 35 minutes after the first error".	8 attempts, the last at 7 h 51 min with storage on; 24 h gaps with it off.	Low: "up to two retries". Medium and High: "up to 12 retries", last at about 1 hour.
On by default?	Not published. Zapier describes autoreplay as something you enable.	Retrying, yes. The storage that lets you retry by hand, no.	Yes.
Switched off eventually?	Auto-pause at "an error 95% or more percent of the times that it has run in the last 7 days", per a page dated 2023.	"If the 8th attempt fails, Make disables scheduling of the scenario."	A consistently throttled flow "is turned off" after 14 days.
What you do by hand	Zap history, On Hold tab, select, Replay. Paid plan, within 60 days, 1 per second.	Incomplete executions tab, select, Retry selected. The scenario must be active first.	Turn the flow on and resubmit runs inside the 30 days.

The pattern is the same in all three. Each retries for a few hours, then gives up somewhere between eight hours and fourteen days. After that the records are either in a list you have to find, or gone from the automation and living only in the source system.

Where an automation stopped syncing after too many requests, which of those two you get was decided in advance, by a setting, on a calm day. On Make it is the storage checkbox. On Zapier it is autoreplay. On Power Automate it is whether anybody reads the emails. Who knows the queue exists, and who may press the button, belongs in the handover checklist.

Why does replaying the backlog throttle you again?

Because pressing Replay on a thousand held records sends a thousand calls at an app that just told you to slow down. Zapier's one a second is deliberate pacing, and still faster than some apps allow. The second refusal looks like the first.

Replaying held Zaps in batches can trip the same throttle again, because the replay is new traffic against the same ceiling.

Whatever put the runs on hold, the way out of the On Hold tab is the same one: open Zap history, filter to On Hold, select, replay. Nobody has automated that step for you.

On Make the do-it-yourself fix is a hand-built wait: an error route with a sleep step and a cloned request step. It is fiddly to get right, and the usual failure is that the error route never starts because the scenario does not treat the refusal as an error.

The version that works for an owner is duller. Replay in batches sized to the ceiling you know about, wait out the window, then do the rest. That waiting is the real cost of a throttled day.

Which switches to flip this week

Pick your platform and spend ten minutes. None of these switches needs a developer, and on a normal day you will not notice any of them; what they change is how much survives a bad one. Two of the three lists below take one visit to a settings screen, and the third is a diary entry.

On Make:

Open scenario settings and switch on "Store incomplete executions".
Check the scenario is active before trying to retry anything.
Look at the incomplete executions tab after any busy day. Resolved ones are deleted after 30 days.

On Zapier:

Switch on autoreplay for the Zaps that matter. It is a per-Zap setting, and the owner of a Zap can turn it on.
Open the flood protection setting on any Zap with a polling trigger. It is a paid-plan setting, so check what your plan includes.
Diary a check of the On Hold tab after any campaign, import or odd weekend.

On Power Automate:

Make sure throttling notifications reach somebody who reads them.
Check the retry policy on actions talking to your busiest connector.
A run older than 30 days cannot be resubmitted at all.

Sometimes the honest fix is buying headroom from the app on the other end: a higher Shopify tier, a Workspace plan with a bigger sending limit. That sits with the rest of the running costs in what automation costs a small business.

What do the vendors not publish?

More than you would like, and the gaps sit where an owner needs an answer. I looked for each of these across the pages listed below, in August 2026, and could not find them stated. A missing answer is a finding.

Whether Zapier's autoreplay is on for a new account. Every page I read describes it as something you enable. None says what the default is.
Whether a "Throttled by Zapier" run is autoreplayed. Zapier's page on that error says the run "errors and has a stopped status". The replay documentation describes autoreplay acting on the errored status. Zapier does not join them up.
Which errors Make retries. The retry page names RateLimitError, ConnectionError and ModuleTimeoutError; the exponential backoff page names only the last two. The eight-attempt schedule above is the retry page's.
Whether Power Automate queues throttled trigger events. Microsoft documents retrying an action and disabling a flow. A queue of records waiting for the throttling to clear does not appear on the pages I read.

Test your own account. A throttled day looks like a slow day from every screen you own, and the only place the difference shows is in the records that never arrived. If you would rather have the ceilings mapped across everything you run, with a figure against each, that is what the audit is for.