Make.com Limits: Credits, Modules, Webhooks, Storage, and What Actually Caps Out

Last updated: May 2026

Table of contents

1. The 30-second answer
2. A note on terminology
3. Module-level limits
4. Scenario-level limits
5. Polling and trigger limits
6. Account-level limits
7. Pricing-tier-related limits
8. Quick reference: the Make limits most operators actually hit
9. The pattern that runs through these
10. Frequently asked questions
11. Sources

---

You hit a Make limit. Maybe the scenario stopped halfway through with “module execution timed out.” Maybe an HTTP module returned “payload too large.” Maybe your data store stopped accepting new records and you can’t figure out why. Maybe a 1,000-record sync mysteriously processed 3,200 records and stopped.

Every one of those is a Make limit doing exactly what it’s supposed to do. The question isn’t “is something wrong with Make?” — it’s “which limit did you hit, and what’s the right architectural response?”

This is the reference. Every limit that matters, in order of how often it bites operators, with what to do when you hit each.

The 30-second answer

The limits you’ll most often hit, ranked by frequency:

• 40-second per-module timeout. Any single module that takes longer than 40 seconds to respond gets killed. Usually an upstream API problem.
• 3,200-result search cap. Search modules return at most 3,200 records per run, no matter what limit you set.
• 5 MB per-module data limit. A single module cannot pass more than 5 MB of data downstream.
• 15-minute polling minimum on Free plan, 1-minute on paid. Hard floor — can’t poll faster.
• 40-minute total scenario execution on paid plans (5-minute on Free). A scenario that runs longer than its plan-tier maximum gets killed.
• 300-second (5-minute) Sleep maximum. The Sleep module caps at 5 minutes per call.
• 2 active scenarios on Free plan. Hard cap — you can only have 2 scenarios scheduled at once.
• Data stores: 1 MB default, 1,000 max per organization. Bigger than most operators expect to fit; smaller than the few who want lots of large stores assume.

Each of these has a workaround. The workaround is almost always architectural — splitting work into smaller chunks — rather than upgrading a plan.

A note on terminology

This article uses credits and operations somewhat interchangeably. Make renamed its billing unit from operations to credits in August 2025, but for standard non-AI modules the math is the same: 1 module run = 1 credit (which is the same as 1 operation). See Make.com Operations vs Credits for the full explanation of the rename and what counts. Where Make’s official docs still use “operations” (e.g., the operations help page), that’s the legacy term for the same thing.

Module-level limits

These apply to every module in every scenario, regardless of plan.

40-second module timeout

A single module run cannot take longer than 40 seconds. If the external service it’s calling doesn’t respond in 40 seconds, the module errors with a timeout.

This is most often an upstream API problem rather than a Make problem. The fix depends on which:

• If the API is slow — use the API’s pagination if available (request smaller chunks), use HTTP-with-streaming if the API supports it, or pre-filter the request to return less data.
• If the API has a slow specific endpoint — split the work. Run one scenario that triggers the slow operation, write the request ID to a Data Store, and have a second scenario poll for completion.
• If you’re hitting it on AI calls — most LLM APIs respond within 40s for short prompts but exceed it for long completions. Stream the response if the API supports it, or break the prompt into chunks.

The 40-second timeout is separate from the scenario-level execution-time limit below (5 min Free / 40 min paid) — don’t conflate them. A module that runs in 30 seconds is fine even if the whole scenario takes 38 minutes (on a paid plan).

5 MB per-module data limit

A single module cannot output more than 5 MB of data into the bundle that flows downstream. If a module tries to (say, an HTTP call that returns a 12 MB JSON response), you’ll get a data-size error.

This 5 MB module/bundle-processing limit is separate from Make’s plan-based maximum file size limit. Make’s pricing page lists max file size by tier (Free 5 MB, Core 100 MB, Pro 250 MB, Teams 500 MB, Enterprise 1000 MB) — that file-size cap governs file uploads and certain file-handling modules. The 5 MB module-bundle limit governs how much data any single module can emit into its downstream bundle, regardless of plan.

The fix for the module-bundle limit is to consume the data in chunks rather than as one blob:

• For paginated APIs — request smaller pages.
• For file downloads — use Make’s file modules to write to a temporary store rather than holding the file in a bundle.
• For large search results — use the search module’s own pagination rather than asking for max results at once.

This limit catches operators who design “fetch everything, then process” workflows. The Make-native pattern is “fetch a chunk, process it, fetch the next chunk.” Both architectures get the same work done; the chunked one stays under the limit.

3,200-object search result cap

Any search module (Search Rows, Search Records, List Items, etc.) returns a maximum of 3,200 records per execution. Set the limit to 10,000 and you’ll still get 3,200.

This is a soft data integrity gotcha: if your source has more than 3,200 matching records and you don’t realize the cap exists, your downstream logic silently runs on a subset. No error fires.

The fix is one of:

• Paginate explicitly — search for records 1-3,200, then 3,201-6,400, etc., using a date filter or ID range to step through.
• Narrow the search filter — most searches don’t need 3,200 results; the cap is being hit because the filter is too loose.
• Use a different access pattern — if you’re trying to sync a large dataset, a polling watcher on new records is usually right, not a search-all-records-each-run.

Scenario-level limits

These apply per scenario execution.

Total execution time (plan-dependent)

Scenario execution time is 5 minutes on Free, 40 minutes on Core/Pro/Teams/Enterprise. A scenario that runs longer than its plan-tier maximum gets killed mid-flight, regardless of how many modules are done or how many bundles are still in process. Whatever wrote to external services before the kill is committed; whatever was in flight when the kill hit is lost.

This is the limit that bites long-running data sync scenarios. The fix is structural and works on any plan:

• Process in scheduled batches — instead of “sync all 10,000 records once a day,” do “sync 500 records every hour.” Each run stays well under the cap.
• Use Make’s incremental triggers — Watch Rows / Watch Records track where they left off and only process new items each run, naturally splitting work over many runs.
• Split the work into multiple scenarios — a parent scenario that orchestrates and child scenarios that process chunks.

If you’re consistently hitting Free’s 5-minute cap on real production work, that’s a stronger signal than usual that you’ve outgrown Free — the architectural workaround (more frequent smaller runs) bumps you into the 2-active-scenarios cap fast.

300-second (5-minute) Sleep maximum

The Sleep module pauses scenario execution for a configured number of seconds. The cap is 300 seconds — 5 minutes. You cannot Sleep longer than that in a single call.

If you need a longer pause:

• Stack multiple Sleep modules — three Sleep modules at 300s each gives you a 15-minute pause. Each Sleep is one credit, so this is cheap in credit terms but expensive in scenario-budget terms (eats into the scenario’s total execution time, which is 5 minutes on Free and 40 minutes on paid plans).
• Use scheduled re-runs — write the pending work to a Data Store, end the scenario, schedule a separate scenario to pick it up later. Better than Sleeping for hours because it doesn’t consume the scenario’s execution-time budget.

The 5-minute cap exists because Sleep ties up scenario resources. Long pauses are an anti-pattern; they’re an attempt to do scheduled work inside a scenario instead of using Make’s actual scheduling features.

Polling and trigger limits

How often a polling scenario can fire.

Polling interval minimums by plan

• Free plan: 15-minute minimum
• Core plan and above: 1-minute minimum

This is the limit that most often pushes operators from Free to paid. A workflow that needs to respond to events within a few minutes can’t run on Free. The economic case for upgrading isn’t usually the credit count — it’s the polling floor.

For triggers that support webhooks (most major SaaS), use webhooks regardless of plan tier. Webhooks aren’t subject to polling intervals because they’re event-driven, not time-driven. A webhook-triggered scenario sits idle until something actually fires it, consuming zero credits during idle time.

Full credit-cost math for polling vs webhook patterns is in Make.com Operations Explained.

Account-level limits

These apply per organization, not per scenario.

Active scenarios on Free: 2

The Free plan caps active (scheduled) scenarios at 2. You can build as many scenarios as you want; only 2 can be set to “On” at any time.

The cap is what kills the Free plan for any operator past the experimentation stage. Production work almost always involves more than 2 scheduled scenarios — at minimum, a worker scenario plus an error-handler audit scenario (see Make.com Error Handling for the recommended audit topology). If you’ve hit this cap and the workflows are real, you’ve outgrown Free. Upgrade here or use the same link to create a paid account from scratch.

Paid plans remove the active-scenarios cap entirely.

Data stores: 1,000 max per organization, ~1 MB default size

Make caps an organization at 1,000 data stores total. This is more than most operators ever approach.

Each data store has a default size of 1 MB. Data store space scales with your plan — Make allocates roughly 1 MB of storage per 1,000 monthly credits. So a Free plan (1,000 credits) gets ~1 MB total across all stores; a Core plan with 10,000 credits gets ~10 MB; and so on.

The “I’ve hit the data store wall” failure mode is usually the space ceiling, not the count cap. Operators who think they need more than 1,000 stores almost always need fewer stores with more records, not more stores. The fix when you hit the space ceiling is either a larger plan or moving cold storage out of Make entirely (write to S3, Postgres, Airtable, etc., and use Make for the active working set).

Webhook queues

Each webhook queue allows roughly 667 items per 10,000 licensed monthly credits, up to a hard ceiling of 10,000 queue items. Make can process up to 300 incoming webhook requests per 10 seconds. When the queue fills up, new incoming requests start getting dropped.

In practical terms: webhook queueing is generous for most scenarios, but it’s not infinite. If you’re consistently queuing webhooks (visible from the scenario’s queue indicator), the fix is to make the receiving scenario faster — offload work to a sub-scenario that runs async, write the payload to a Data Store and process later, or split the receiver into a lightweight intake + a separate worker — rather than to ask Make to queue more.

The 300-requests-per-10-seconds ingestion cap is rarely an issue except during traffic spikes much larger than the scenario can keep up with. If you regularly receive bursts at or above that rate, you’ll need a buffer architecture in front of the webhook (a lightweight ingestion service, a queue, or a dedicated webhook receiver scenario whose only job is to drop incoming payloads into a Data Store).

Pricing-tier-related limits (the volatile ones)

Specific dollar amounts and credit allocations per tier change frequently. Stable mechanics:

• Free plan: 1,000 credits/month, 2 active scenarios, 15-min polling minimum, 5-min scenario execution time, 5 MB max file size
• Core plan: removes the 2-scenario cap, drops polling to 1 minute, raises scenario execution time to 40 min, raises max file size to 100 MB, includes a meaningful credit allocation
• Pro plan: more credits, more storage, 250 MB max file size, advanced features
• Teams plan: per-seat pricing, shared organization pool, 500 MB max file size
• Enterprise: custom, 1000 MB max file size

I deliberately don’t quote dollar figures or specific credits-per-tier counts here. Make changes pricing every 12-18 months and any number I print will be wrong soon. Check make.com/pricing when the answer matters.

---

Want a one-page limits cheat sheet? The free Builder’s Companion Kit includes a reference card with every Make limit on one page, plus the Operations Cost Estimator and five other production-grade tools. Get the kit →

---

Quick reference: the Make limits most operators actually hit

Limit	Value	Scope	What to do when you hit it
Module timeout	40 seconds	Per module run	Paginate, split work, or stream the upstream API
Module data size	5 MB	Per module output	Chunk the data, write to file store instead of bundle
Search results	3,200 objects	Per search module run	Paginate the search, narrow the filter
Scenario execution time (Free)	5 minutes	Per scenario run	Split into smaller scheduled batches
Scenario execution time (paid)	40 minutes	Per scenario run	Split into smaller scheduled batches
Sleep module	300 seconds (5 min)	Per Sleep call	Stack Sleeps, or use scheduled re-runs
Polling interval (Free)	15 minutes	Per scheduled scenario	Use webhooks where possible, or upgrade
Polling interval (paid)	1 minute	Per scheduled scenario	Hard floor — use webhooks for sub-minute response
Active scenarios (Free)	2	Per organization	Build more, upgrade to remove cap
Active scenarios (paid)	Unlimited	Per organization	—
Data store count	1,000	Per organization	Consolidate to fewer stores
Data store default size	1 MB	Per store	Expand the specific store or upgrade plan
Data store total space	~1 MB per 1,000 credits/mo	Per organization	Upgrade plan, or offload cold storage
Webhook queue per scenario	~667 items per 10,000 monthly credits, max 10,000	Per webhook	Optimize the receiving scenario for speed
Webhook request ingestion	300 incoming requests per 10 seconds	Per webhook	Add a buffer architecture if you exceed this in bursts
Max file size (Free / Core / Pro / Teams / Enterprise)	5 / 100 / 250 / 500 / 1000 MB	Per file	Plan-dependent; upgrade to lift

The full reference, including the less-common limits (organization seat counts, API call limits, etc.) and the recommended scenario topologies for working around each, is in Appendix C of The Missing Manual for Make.

The pattern that runs through these

Most Make limits exist to keep individual scenarios from monopolizing platform resources. The right response to hitting one is almost never “ask Make for more” — it’s “split the work into pieces small enough to fit.” The 40-second module timeout, the scenario execution-time cap (5 min Free / 40 min paid), the 5 MB module-bundle limit, the 3,200-result search cap, the 300-second Sleep maximum: all of them push you toward the same architectural pattern. Smaller chunks, more runs, persistent state in Data Stores between runs.

Operators who design with that pattern from the start almost never hit the limits. Operators who design “do all the work once” workflows hit one of these limits within their first month of real volume and spend the next month refactoring. Save yourself the refactor — design chunky from the start.

The Scenario Planning Worksheet in the free Builder’s Companion Kit walks through the chunked-design pattern with worked examples. Use it before the first build, not after the first refactor.

---

Grab the free Builder’s Companion Kit. Includes the Make Limits cheat sheet, Operations Cost Estimator, module reference cards, Production Readiness Checklist, Scenario Planning Worksheet, and six importable starter blueprints. One download, no upsell.

Get the kit →

---

Frequently asked questions

What is the 40-second timeout in Make? It’s the maximum amount of time a single module run can take before Make kills it with a timeout error. Applies to every module in every scenario regardless of plan. If an external API takes longer than 40 seconds to respond, the module errors. The fix is almost always architectural — paginate the request, stream the response, or split the work into a trigger-and-poll pattern across two scenarios.

What is the scenario execution time limit in Make? A scenario’s total execution time across all its modules cannot exceed the plan-tier maximum: 5 minutes on Free, 40 minutes on Core/Pro/Teams/Enterprise. After that, Make kills the run mid-flight regardless of progress. This is separate from the per-module 40-second timeout. The fix is to process work in smaller scheduled batches rather than trying to do everything in one long run.

How big can a Make Data Store be? The default size is 1 MB per store. You can expand specific stores, but total Data Store space across your organization scales with your plan — roughly 1 MB per 1,000 monthly credits. A Free plan gets ~1 MB total; a Core plan with 10,000 credits gets ~10 MB. The max count is 1,000 stores per organization, which is more than most operators ever need.

Why does Make return only 3,200 search results when I asked for more? The 3,200-object cap is Make’s hard limit on search module results per execution, regardless of what limit you set. If your source has more than 3,200 matching records, your downstream logic silently runs on a subset and no error fires. Paginate the search explicitly (date-range or ID-range), narrow the filter, or use a polling watcher pattern instead of search-all-each-run.

Why can’t I poll faster than 15 minutes on Make Free? The Free plan’s 15-minute polling minimum is a hard floor. The Core plan and above drop the minimum to 1 minute. The 15-minute cap is what most operators upgrade out of — the economic case for going paid isn’t usually credit count, it’s the polling floor on time-sensitive workflows.

What’s the difference between operations and credits in Make limits? Make renamed its billing unit from “operations” to “credits” in August 2025. For standard non-AI modules, 1 operation = 1 credit. Limits expressed in either unit refer to the same underlying mechanic — most Make docs still use “operations” interchangeably with “credits” in limit discussions. AI modules use dynamic credit logic separately; see Make.com Operations vs Credits.

Can I increase Make’s hard limits? Some limits are hard architectural limits that apply on every plan including Enterprise: the 40-second module timeout, the 3,200-result search cap, the 5 MB module-bundle data limit, and the 300-second Sleep cap. These exist to protect the platform from individual scenarios monopolizing resources; the fix is always architectural — split the work into pieces small enough to fit.

Other limits are plan-dependent and can be increased by upgrading: scenario execution time (5 min Free / 40 min paid), active scenarios (2 Free / unlimited paid), polling interval (15 min Free / 1 min paid), maximum file size (5 MB Free → 1000 MB Enterprise), data store space, and data transfer.

Sources

Verified live as of May 29, 2026:

• Make Help Center — Operations: help.make.com/operations
• Make Help Center — Credits: help.make.com/credits
• Make Help Center — Webhooks: help.make.com/webhooks
• Make Help Center — Types of modules: help.make.com/types-of-modules
• Make Pricing: make.com/en/pricing

Specific numeric limits in this article (40-second module timeout, 5-min/40-min scenario duration by plan, 5 MB module-bundle data, 3,200 search cap, 300-second Sleep maximum, 1 MB data store default, 1,000 data store count, polling minimums, webhook queue and ingestion limits) were verified against live Make docs in May 2026.

---

Brian Kasday writes The Operator’s Library for MMS Vegas — production-grade reference manuals for the tools small operators actually run. The Missing Manual for Make is the long-form companion to articles like this one.