What happens to your automations when the plan runs out

August 31, 202615 min readUpdated September 13, 2026

Somewhere in a busy month, an automation nobody has thought about since it was built will reach your automation plan limit, which is the last unit of work your subscription pays for. What happens in the following minute is decided entirely by the platform. The five platforms small businesses tend to use behave in five different ways.

Zapier holds everything and lets you replay it later. Make switches off every scenario in the account at once, then queues incoming webhooks until the queue fills. Power Automate slows you down for a fortnight and then turns the flow off until somebody turns it back on. The other two do not publish an answer at all, which is its own answer if your orders go through them.

Almost all the advice on this subject describes Zapier, which is unlucky, because Zapier is the one that behaves best. "Runs are held, nothing is lost" gets repeated as though it were a rule of the category. It is a description of one vendor's design decision.

What actually happens when you hit the automation plan limit?

One of four things, depending on the platform: your work is held for later, the workflow is switched off, incoming traffic is slowed down, or nobody has written down what happens. That last one turns up more often than it should, and it is the case worth checking before you need the answer rather than during the week you do.

What matters to you is whether the order that arrived at 11am on the day you ran out still exists somewhere. A held run is recoverable, if you know it is there and somebody presses the button. A switched-off workflow means the trigger fired against nothing at all. A queue means you are fine until the queue is full, and then you are not.

Everything below comes from the vendors' own documentation, read in August 2026, with the sentence that supports each claim quoted. Where a vendor does not document its behaviour, that is written down too, instead of being filled in from somebody's blog. Plans and limits move, so check the numbers against the vendor's page rather than against this one.

Which platforms hold your work, and which switch it off?

I could not find this comparison published anywhere, so it is assembled below from the five vendors' own pages, with the gaps noted where the vendor is silent. Read the last column first. That is the one that decides whether the morning after is an inconvenience or a phone call to a customer.

Platform	At the limit	What happens to new triggers	Can you get the work back?
Zapier	Runs go to a status called `On hold`	Held, not run	Yes, by replaying manually, within 60 days
Make	All scenarios in the organisation are paused immediately	Webhooks queue, then are rejected once the queue is full	Yes, automatically on resume, up to the size of the queue
n8n Cloud	Not documented; the working assumption is that active workflows are paused until the 1st of the month	Not documented	Not documented
Power Automate	Activity is slowed, and after 14 days the flow is turned off	Slowed, then nothing	No documented replay
Pipedream	Not documented; the Free tier limit is daily rather than monthly	Not documented	Not documented

Two of the five give you the work back: Zapier by manual replay, Make by replaying its webhook queue. Power Automate documents no replay of what arrived while a flow was off. The remaining two are a blank space in the manual, and if invoices, bookings or orders run through one of those blank spaces, find out before the month it matters.

Why does Zapier's own recovery skip this case?

Because the feature that replays failed runs for you deliberately does not cover held ones, which is exactly the state a plan limit produces. Zapier is the most forgiving platform in this comparison, and it still needs a person to log in and press a button before your Monday arrives in your inbox.

The good part is real. Zapier's help centre says that when you hit your task limit, "Your Zap runs will be held, not lost. Held runs are paused and can be replayed from your Zap History once you have available tasks." The runs sit under a status the interface calls On hold, which also covers disconnected accounts and payment problems, so seeing it does not tell you which of your problems you have.

The first of three limits on that promise is time. Zapier's replay page says: "You must replay steps within 60 days of the initial trigger event." Its history page puts a ceiling under that, guaranteeing "a maximum of 60 days" of run data and displaying up to 10,000 runs. A busy account can pile up more held work than it can see on screen.

The second is that replaying is billed like new work: "Any successful steps will count towards your task usage, even if they were already counted in a previous run." Catching up on 2,000 held tasks therefore costs 2,000 tasks out of the allowance you have just restored.

And the third is that none of this is automatic. Zapier's own page on replay says plainly: "Autoreplay will not replay Zap runs with an on hold status. You must manually replay them in Zap history or in the Zap editor instead."

So the platform with the kindest behaviour in this group still leaves you a manual recovery job, on a clock, that spends quota to perform. All of it depends on somebody noticing in time.

If you would rather have somebody work out which of your processes sit on this kind of edge, that is what the process audit produces. $299, three business days, and a written map you keep whether or not you hire us. Part of it is what each process costs you when it stops for a day.

What happens to the webhooks while everything is paused?

They queue, and the queue is smaller than you think. A webhook here means the other system pushing you an event the moment it happens: an order placed, a form submitted, a payment taken. Make stores those while everything is off, and the size of that store is the number nobody checks until the week they need it.

Make's error documentation says that a module returns OperationsLimitExceededError when you run out of credits, and that "Because the OperationsLimitExceededError is a fatal error, Make immediately disables the scenario scheduling, regardless of the number of consecutive errors." Normally Make tolerates a configured number of failures before it deactivates anything. Running out of credits skips the tolerance in one step.

It is also not confined to the scenario that spent the credits. The credits belong to the organisation, not to the scenario, so when they run out every scenario in the organisation stops and incoming webhooks go to the webhook queue. A test scenario left running over a weekend takes your order processing down with it.

That queue is the other half, and it replays automatically once credits return. Its size is documented: "For every 10,000 credits licensed per month, you can have up to 667 items in each webhook's queue. The maximum number is 10,000 items in the webhook's queue." On a 10,000-credit plan that is roughly 667 items of protection per webhook. After that, "When the webhook queue is full, Make rejects all incoming webhook data which is over the limit". Unless somebody has built a custom response into the scenario, the sending system gets an HTTP 400 back, which is the code for "I am refusing this".

A refusal is technically visible, which beats silence. Whether anyone sees it depends on whether the system at the other end reports its own failed deliveries to a person, and in a small business it usually does not.

The queue covers webhooks and nothing else: scenarios that poll an API on a schedule, going out every fifteen minutes to ask whether anything is new, have no documented equivalent. Whether records that scrolled out of the source system's own window come back is not written down anywhere I could find.

Why can nobody tell you what n8n and Pipedream do?

Because neither vendor publishes it, and both publish something adjacent that is easy to mistake for it. The gap itself is the finding: two of the five leave the question unanswered, and their customers plan around a guess.

n8n documents concurrency, which is how many executions run at the same time. Its docs say that "Any executions beyond the limits queue for later processing. These executions remain in the queue until concurrency capacity frees up, and are then processed in FIFO order." FIFO means first in, first served, and the behaviour is genuinely good. It also describes traffic spikes. Your monthly allowance is a different counter, and the documented queueing does not cover it.

What happens when the monthly execution allowance is gone is not on docs.n8n.io, and nothing on its forum from n8n itself settles it either. The working assumption, and it is an assumption, is that active workflows are paused until the count resets at the start of the next month. A business should not have to plan on an assumption, and here it does.

Pipedream has the same shape. It documents that the limit exists: "On the Free tier, Pipedream imposes a limit on the daily credits across all workflows and sources." Daily, note, not monthly, so a free-tier outage is something that can happen every day instead of once a cycle. It also documents a separate rate limit of about ten requests per second on an HTTP trigger, which returns a 429 and is a different mechanism entirely.

What it does not document is what a webhook caller gets when the credits are gone, whether the event is queued, or whether it is kept at all. Nobody from Pipedream has said publicly what happens to the events, and the people who have hit the quota and asked have not been told either.

A ceiling that produces no record is the same problem as a workflow that fails silently, arriving by a different road. Where you cannot tell a quiet week from a stopped system, the quota becomes one more way to be wrong about which one you are having.

Does Power Automate really switch a flow off by itself?

Yes, and Microsoft publishes the exact conditions under which it will. That makes Power Automate the only one of the five that tells you in advance it will stop running your business process. The sequence has two stages, and the second lasts until a person intervenes.

The first stage only slows you down. Microsoft's limits page says that "If a cloud flow exceeds one of the limits, flow activity slows. It automatically resumes when the sliding window has activity below the limit. However, if a cloud flow consistently remains above the limits for 14 days, the system turns it off."

The retention table on the same page sets out three shutdown rules:

A flow whose trigger or actions "fail continuously" is turned off after 14 days.
A flow that is "consistently throttled" is turned off after 14 days.
A flow not triggered within a 90-day period "might be turned off", with owners and co-owners notified 30 days in advance.

The third rule comes with a warning. The two that fire in a fortnight do not.

Now read the notification rules against that fortnight. Microsoft documents that after a failure alert is sent for a flow, "there's a 28-day cooldown period before another per-run alert can be sent for the same flow." It also documents that when the system cannot identify a specific fix, no alert is sent at all, by design, and that per-run failure alerts "aren't enabled for all flows by default."

So a flow can fail on the first of the month, send one email, go quiet for 28 days, and be switched off on day 14 with nothing further said. The documented backstop is a weekly digest. That is a weekly digest underneath a fortnightly kill switch.

How would you find out that it happened?

Mostly by email, which is to say mostly not at all. Every platform here has a notification story, and each has a hole in a different place. The useful question is whether the telling reaches somebody who can act on it today.

Platform	What you are told
Zapier	Emails as you approach and reach the limit
Make	Warning, error and deactivation emails, configurable per organisation
n8n Cloud	Not documented
Power Automate	Per-run alerts, off by default for some flows, capped by a 28-day cooldown, plus a weekly digest
Pipedream	An in-app warning; whether an email is sent is not documented

The alert goes to whoever owns the account. In a small business that is often the person who set the thing up two years ago, and who may not work here any more. The predictable response to a monthly email about several hundred held tasks, from somebody who does not know what a held task is, is to go in and delete them. It is a reasonable response to an email you do not understand, and the destruction of every recoverable order in the list.

The check worth doing is smaller than a monitoring project. Open the billing page of whatever you use and look at usage against allowance, today. My own rule of thumb, and it is a rule of thumb and not a measurement: above 70 percent with a week of the month still to go tells you what next month looks like.

Why does the bill arrive twice?

Because the recovery consumes the same allowance that ran out, and on some plans the overage is charged at a premium on top of that. Running out costs you twice: the work you lose on the day, and the quota you spend getting it back afterwards.

Zapier is explicit that replayed steps count again. Make's queued webhooks process as ordinary operations when the scenario resumes, out of the new month's credits. Whatever you are on, the month after an overrun starts with a debt to itself.

The rest of that arithmetic is in what automation costs a small business: what the tiers cost, and why a five-step workflow firing 150 times eats an allowance faster than the number suggests. So the ceiling shows up on the invoice and in the operation on the same day, and the recovery carries its own price.

What to do before you get near the ceiling

None of this needs a budget or a developer. In the order I would do it:

Find out what your platform actually does, which is rarely what the category is said to do. Open your vendor's help centre and search for the limit. If you cannot find an answer in ten minutes, you have learned something important.
Look at usage against allowance today, and again on the same day next month. Two readings give you the trend. That is the number to plan against.
Ask what would still be true if it stopped for a day. Orders that arrive by email are recoverable by hand. Orders pushed straight into a paused scenario may not be.
Put the alert where somebody reads it. Billing and failure notices go to the account owner by default. If that is an old address, or a person who has left, fix it before anything else on this list.
Know who presses the button. Held work does not replay itself on any platform here. Make comes closest, and what it replays is a queue of webhook payloads of a documented size.

Number three is the one that changes decisions. Where the honest answer is that you would lose the enquiries, the process needs a path that survives the platform being off, and that is a design question. No plan tier fixes it.

What to ask whoever builds this for you

Four questions, and they belong in the handover conversation instead of in a crisis. Anybody who builds automations for a living can answer them in a minute, and the answers should be written down where you can find them later.

What is the limit on the plan we are on, and what does the vendor say happens when we reach it?
Who gets the email, and is that an address somebody reads?
If we go over on a Friday, what state is the work in on Monday, and who recovers it?
What is the cost of a month where we go over by 30 percent?

That last one belongs on the list of things you should receive when a build is handed to you, alongside what it costs to run and how you know it is working. A proper handover covers the rest of that list. And where a process cannot survive its platform being off for a day, you want to know that before the build starts. It is the same reasoning as not automating some processes at all.

We would rather tell you that a process is fine as it is than sell you a build that quietly depends on a ceiling nobody is watching. If you want the ceilings in your own setup found and priced before anything is built, that is what the process audit is for.