Task Limit Reached: What Happens to Your Automations

When your automation platform runs out of its monthly quota, no run turns red in the usual way, and what happens to the work that keeps arriving depends on the platform. As of October 2026, Zapier holds runs that you replay by hand, Make stops scenarios but queues webhooks until a cap tied to your credits and then answers 400 Queue is full, n8n Cloud fails every execution with Execution limit reached and keeps no backlog, and Power Automate slows flows down over a sliding 24-hour window. The quota is shared by every workflow in the account, so the flow that drains it is rarely the flow that matters, and the lead intake stops because a sync loop ate the month.

Most of what ranks for "task limit reached" is one vendor explaining its own upgrade button. That is useful once you are already stuck. What you need before it happens is knowing which of the four behaviors you are running on, because the recovery is different for each one and so is the damage.

What does each platform do when the quota runs out?

Here is the behavior each vendor documents, checked against their help pages in late September 2026.

Platform	What the meter counts	At the limit	What happens to new events	How you recover
Zapier	Successful action steps. Triggers, filters, paths, Formatter, Delay, and errored steps do not count.	With pay-per-task on (default for accounts since January 2024), Zaps keep running until 3x the plan limit. Then runs are held.	Held in Zap History, not lost.	Replay held runs, up to 5,000 at a time, after upgrading or after the billing cycle resets. Free plans cannot replay held runs.
Make	Credits, one per module operation for most apps. Routers and filters are free.	Scenarios stop until credits are added. Alerts at 75% and 90%.	Webhooks queue: 667 items per 10,000 monthly credits, 10,000 max per webhook. Over that, 400 Queue is full. Polling scenarios later search from their last successful run.	Buy extra credits (25% surcharge) or turn on auto-purchase, which adds 10,000 credits at a time. The queue then drains.
n8n Cloud (Starter, Pro)	Executions. One per workflow run, however many nodes it has.	Workflows stay active; every execution fails before any node runs.	Nothing is queued. Each attempt is a failed execution with Execution limit reached. Consider upgrading your plan.	Upgrade, or wait for the reset on the first of the calendar month, not your billing date. n8n grants one courtesy reset per customer on some plans.
Power Automate	Power Platform requests: every action, including failed ones, retries, and pagination.	Flows over the allocation slow down (throttling) rather than stop.	Runs continue, late.	Assign a Process license to the flow, which gives it its own 250,000 requests per 24 hours.

Read the "new events" column twice. It decides whether running out is an inconvenience or data loss.

Why the same outage costs different amounts on each platform

Zapier: nothing is lost, but everything is late. Held runs sit until someone replays them. That is the safest default of the four, with one trap: replay runs the work now, not when it was due. A held "send the welcome text" run replayed four days later sends a welcome text four days late. A held "create invoice" run replayed after you already invoiced by hand creates a second invoice. Before you click replay on 2,000 held runs, sort them by which actions are still correct to perform late.

Make: safe until the queue fills, then silently lossy. The webhook queue is sized by your plan. On a 10,000-credit plan each webhook holds 667 items. A lead form taking 30 submissions an hour fills that queue in about 22 hours. After that, Make returns 400 Queue is full to the sender, and many senders do not retry a 4xx. Those leads exist only in the source system now, if they exist anywhere. Polling scenarios fare better, since Make says they search for records since their last successful run, so a scheduled "watch new rows" picks up the gap on its own.

n8n Cloud: loud in the log, empty in the backlog. The triggers keep firing and every execution fails instantly, so your execution list fills with red. That looks like visibility, but it is not recovery. The webhook payloads that hit those failed executions are not waiting anywhere. When the month resets, you are rebuilding the gap from source systems, which is a backfill job, not a replay.

Power Automate: slow, not stopped. Throttling keeps runs going, which is good for a nightly sync and bad for anything with a clock on it, like a missed-call text-back. A flow that normally answers in seconds and now answers in an hour has failed for the customer even though every run eventually succeeds. Plan for where the limit lands, too: Microsoft says automated and scheduled flows use the limits of the flow's owner, and once its current transition period ends, Premium limits apply per user, so a heavy flow owned by one person will slow down every other flow that person owns.

Which flow actually drained the quota?

The meter decides the culprit, and it is rarely the big, important workflow.

• On n8n, frequency is the drain. One execution per run means a 10-node workflow and a 1-node workflow cost the same. A single schedule trigger every 15 minutes is 96 runs a day, about 2,880 a month, which is more than the Starter plan's 2,500 executions on its own. Every-minute polling is 1,440 runs a day and empties Starter in under two days. n8n's community forum has threads asking for a limit reset after exactly this: a schedule trigger set more often than intended.
• On Zapier, loops are the drain. Only successful actions count, so a Zap that fails loudly costs nothing, and a Zap that succeeds in a circle costs everything. The classic shape: a Zap triggers on "updated record" in the CRM and its action updates that same record, which triggers it again.
• On Make, polling plus fan-out. The trigger costs a credit each time the scenario runs, and an iterator that splits one bundle into 200 line items runs every downstream module 200 times.
• On Power Automate, retries. Failed actions, retries, and pagination all count, so a flow stuck retrying a down API spends the allocation while doing no work. Our piece on when an automation should retry covers the retry limits that keep this bounded.

The pattern underneath: quota exhaustion is usually a reliability bug wearing a billing costume. Something is running far more often than it should, and the bill is the first alarm anyone sees.

How to keep one runaway flow from stopping the rest

We set these five things up on any account where the automations carry revenue.

1. Write down each flow's expected monthly usage. Runs per month times units per run, in the platform's own unit. It takes ten minutes with a spreadsheet and it turns "we are at 80%" from a mystery into "the inventory sync is at 4x its budget."
2. Alert on your own count, before the vendor does. Zapier emails as you approach and reach the limit, Make at 75% and 90%, and those emails go to whoever owns the account, who may not be the person on call or may have left. Log one row per run to your own store and alert a shared channel when any single flow exceeds its daily budget by 3x. That catches the loop on day one, not on day 24. If you already have a heartbeat from our guide to alerting when an automation stops running, add the usage check to the same watchdog.
3. Put the flows you cannot lose on their own meter. A separate Zapier or Make account, a separate n8n instance, or a Process license on the one Power Automate flow that takes leads. The goal is that an experiment or a sync loop cannot consume the lead intake's capacity. This costs a second subscription; one lost day of inbound leads usually costs more.
4. Turn on overage for revenue flows, deliberately. Zapier pay-per-task and Make auto-purchase are the right call when a lost order costs more than a 25% surcharge. Turn them on knowing the ceiling (Zapier stops at 3x the plan limit, Make caps auto-purchases at your subscription's credit count) so the overage is headroom, not a blank check.
5. Make the source of truth replayable. If the quota fails on n8n, or a Make queue overflows, you recover from the source system, not from the platform. Every intake that matters should also land somewhere you control, so a gap can be rebuilt by date range. Our piece on missed webhooks when an endpoint was down covers the same recovery from the sender's side.

What to do this week

Open your platform's usage page today and write two numbers next to each other: what you have used so far this cycle and how many days are left. If the straight-line projection crosses your limit, find the top flow by usage and check its trigger frequency and whether it writes back to its own trigger. Then look at the "new events" column in the table above for your platform and decide, in writing, what happens to a lead that arrives on the day you run out.

If you want help sizing usage per flow and splitting critical automations onto their own meter, that is part of how we build workflow automation systems. Or tell us what you are running and we will point at the flow most likely to drain it.