MMS Vegas

Tag: reference

  • Make Data Stores: How They Work, When to Use Them, and the Limits That Will Surprise You

    Last updated: June 2026

    Table of contents

    1. What a data store actually is
    2. When to use one — and when not to
    3. Creating a data store and defining your structure
    4. The five operations you will use
    5. Reading all records: the pagination trap
    6. Using data stores across multiple scenarios
    7. The real limits: size, records, and what happens when you hit them
    8. Quick reference
    9. Frequently asked questions

    Make’s data store is a simple key-value database that lives inside your Make account. You create it, define its columns, and then any scenario you own can read from or write to it — no external database required.

    That sounds modest, and it is. But for the specific problems it solves — remembering what ran last time, deduplicating records across scenario runs, passing state between two unrelated scenarios — it’s the right tool, and the alternatives (Google Sheets as a makeshift database, a paid Airtable base, an external database connection) all cost more friction than the job warrants. The catch is that Make’s documentation explains the mechanics without explaining when and why, and there are several limits that will surprise you if you discover them in production. This guide covers both.

    What a data store actually is

    A data store is a lightweight table — rows and columns — that Make hosts for you. Each data store belongs to your Make team and persists between scenario runs. Unlike a scenario’s internal variables (which reset every run) or the data that flows through a module’s output (which disappears the moment the scenario finishes), a data store keeps its values until you explicitly change or delete them.

    You define the structure: a name for the store, and a list of columns with types (text, number, boolean, date, array, object). One column can be designated the key — Make uses this as the unique identifier for each row. If you don’t designate a key, Make generates a numeric ID automatically.

    That’s the whole model. It’s not a relational database. There are no joins, no foreign keys, no indexes beyond the key column. Think of it as a persistent spreadsheet that your scenarios can read and write to mid-run.

    When to use one — and when not to

    Data stores are the right answer for a short list of problems.

    Deduplication. Your trigger fires for every new record in a source, but some records have already been processed. Store the unique ID of each processed record in a data store, then check for it at the start of each run. If it’s there, skip. If it isn’t, process and write it. This is the most common real-world use of data stores, and it works cleanly.

    Cross-scenario state. Two scenarios need to share a value — a counter, a flag, a last-run timestamp — but they have no other connection. Writing to a shared data store is the cleanest solution. One scenario writes the value; the other reads it. No external system needed.

    Simple queues. You can write records to a data store in one scenario and process them in another, clearing each record once it’s handled. This works well for low-volume queues where strict ordering and delivery guarantees don’t matter.

    When not to use one. Data stores are not the right tool for large datasets, reporting, or anything that requires search beyond the key column. If you’re storing more than a few thousand records, working with data other people need to see or edit, or running queries against values in non-key columns, reach for a proper external database (Airtable, Supabase, Google Sheets for human-readable data, or a direct database connection). Make’s data stores don’t support filtering by arbitrary columns — the “Search records” operation does a full-table scan filtered client-side, which is slow and credit-expensive at scale.

    Before you build with data stores: the free Builder’s Companion Kit includes reference cards for Make’s core features — including a data store cheat sheet — plus six importable scenario blueprints. Get the free kit →

    Creating a data store and defining your structure

    In Make’s left navigation, go to Data stores. Click Add a data store. Give it a name — something specific enough to find later (processed-order-ids is better than my-store). Set the data storage size; the default is 1 MB.

    Next, define your structure. Each row in the structure becomes a column:

    • Name — the column name your modules will reference.
    • Type — text, number, boolean, date, time, date-time, array, or object (object means a nested set of key-value pairs).
    • Is Key? — mark one column as the key. Make uses this for lookups and for the upsert behavior of “Add/Update a Record.” If you don’t set a key, Make uses an auto-generated numeric Key field.
    • Required — if checked, Make will error if a scenario tries to write a record without that field.

    Design tip: always set an explicit key column using a value that’s naturally unique in your data — an order ID, an email address, a combination field. Auto-generated keys make lookups awkward because you’d have to search for a record by a non-key field instead of going straight to it by key.

    You can add columns to a data store after creating it, but you can’t change a column’s type. If you need to change a type, you’ll need to create a new store and migrate the data.

    The five operations you will use

    The Data Store module in Make exposes several operations. Five cover almost every real use case.

    Add a Record. Writes a new row. If a record with the same key already exists, Make throws an error — it does not overwrite. Use this when you know the record is new and want duplicate writes to fail loudly.

    Update a Record. Updates an existing row by key. If the key doesn’t exist, Make throws an error. Use when you’re certain the record exists and want a missing record to fail loudly.

    Add/Update a Record (upsert). Writes the record if the key doesn’t exist; updates it if it does. This is the most useful operation. In most automations, you want “write this value, overwrite if it’s already there” — upsert is that behavior without needing a prior check.

    Get a Record. Reads a single row by key. Returns the record’s fields if found; returns nothing (an empty bundle) if not found. This is how you check whether a record exists — run “Get a Record,” then use a filter to check whether the bundle is empty.

    Search Records. Scans all records in the data store and returns those that match a condition. The condition is applied after retrieval — Make reads every record in the store and then filters. This is the operation to use sparingly at scale: a 5,000-record store with a search runs the condition against all 5,000 rows every time. Use it for small stores or one-time setup scenarios. For anything repeated at volume, structure your data to use “Get a Record” by key instead.

    Delete a Record. Removes a row by key. Irreversible — Make does not prompt for confirmation in a running scenario.

    Reading all records: the pagination trap

    This is the mistake that bites people building queue-style automations or data-sync scenarios.

    The “Search Records” operation — including searching with no filter, to get all records — returns results in pages. You set how many records come back per run with the module’s Limit field, and a large store is returned in pages. Make processes each page as a bundle, and if your scenario doesn’t handle pagination, it processes the first 100 rows and stops.

    The fix: in the Search Records module settings, there’s a Limit field. Set it to the maximum number of records you expect. If your store might grow, build the scenario to iterate through pages using the iterator pattern or accept that the limit needs periodic adjustment. A cleaner design for large datasets is to structure your key so you can retrieve records one at a time by key rather than scanning.

    The second trap is writing to a data store while iterating over it. If your scenario reads all records, processes each one, and deletes records as it goes, Make may re-read pages mid-iteration and either miss records or double-process them. Safe pattern: read all records first (into an array aggregator), then process each record from the aggregated list, then delete. That way your read is complete before any writes happen.

    Using data stores across multiple scenarios

    A data store isn’t locked to the scenario that created it. Any scenario in your team can read from or write to any data store in the same team account. This is the feature most documentation underplays.

    The practical implications are significant. You can build a “writer” scenario that collects data from several sources and normalizes it into a data store, and a separate “reader” scenario that runs on a different schedule and consumes that data. You can use a data store as a shared configuration table — one scenario reads a set of settings from the store, another updates them via a webhook trigger. You can implement a simple mutex by checking for a flag in a data store before a scenario proceeds.

    Concurrency caveat: Make does not lock a data store record while a scenario reads it. If two scenario runs execute simultaneously and both read-then-write the same key, you can get a race condition — the second write overwrites the first without seeing it. For most small-operator use cases this doesn’t matter. If you’re building something where simultaneous runs are likely and the data must be consistent, either design the key structure so each run writes a distinct key, or ensure the scenario is set to run sequentially (Make’s scenario settings have a “Sequential processing” option for this).

    Related: if your data store use case is really about reliable state across retries and error handling, the companion article on Make error handling covers the full picture of how Make persists (or doesn’t persist) bundle state when scenarios fail.

    The real limits: size, records, and what happens when you hit them

    Data stores have two limits that matter: storage size and the number of data stores per team.

    Storage size. Each data store has a maximum size in megabytes, set when you create it. The default is 1 MB. You can increase it at creation time or by editing the store later, up to the per-store ceiling your plan allows — 1 MB by default on the entry Core plan, more on Pro and Teams, and custom on Enterprise (check make.com/pricing for your plan’s current figure). When a data store hits its size limit, Make throws a “Data store is full” error on the next write attempt. The scenario doesn’t partially succeed — the write fails and the scenario errors. Monitor your data store sizes in the Data Stores panel; Make shows current usage versus the limit for each store.

    Number of data stores. You can create up to 1,000 data stores per organization, regardless of your plan. If you hit that limit, Make won’t let you create a new store. The fix is to either upgrade your plan or consolidate stores — multiple logical “tables” can live in the same store if you use a composite key (e.g., prefix the key with the entity type: order:12345 vs customer:67890).

    Record count. There’s no hard record-count limit independent of the size limit — you can have as many records as fit in the allocated megabytes. A 1 MB store with lean text records can hold several thousand rows. A store with records containing long text fields or nested objects fills up faster. Design accordingly: store IDs and compact values, not full document content.

    What happens when you hit a limit. Make throws an error on the operation that breached the limit — it doesn’t silently drop data. The scenario logs the error, and if you have incomplete execution handling enabled, the failed bundle is parked for review. This is the right behavior, but it means you need to monitor your data stores actively if they’re on a growth path. There’s no built-in Make alert for “data store approaching capacity.” If that matters to your operation, build a monitoring scenario that runs daily, reads the store’s current size and record count via the Make API — the data store GET endpoint returns size, records, and maxSize — and sends an alert if usage exceeds a threshold.

    Quick reference

    Operation What it does Error if missing? Use when
    Add a Record Creates a new row Yes — errors if key exists Record is guaranteed new
    Update a Record Updates an existing row by key Yes — errors if key missing Record is guaranteed to exist
    Add/Update (upsert) Creates or overwrites No Most writes — safest default
    Get a Record Reads one row by key No — returns empty bundle Check existence; targeted reads
    Search Records Scans all rows, filters by condition No Small stores; setup/one-off runs
    Delete a Record Removes a row by key No Clearing processed queue items

    Frequently asked questions

    Can two scenarios use the same data store at the same time? Yes — any scenario in your team can read from or write to any data store in the same account. There are no locks, so if two scenario runs execute simultaneously and both write to the same key, the second write wins. For most use cases this doesn’t matter; if it does, enable sequential processing on the scenario or design keys so concurrent runs write distinct rows.

    What’s the difference between Add a Record and Add/Update a Record? Add a Record errors if the key already exists — it will not overwrite. Add/Update a Record (upsert) creates the record if it’s new or overwrites it if it already exists. In most automations, upsert is the right default because it handles both cases without requiring a prior existence check.

    How do I check if a record exists without erroring? Use “Get a Record” by key. If the record exists, Make returns it. If it doesn’t exist, Make returns an empty bundle — not an error. Add a filter after the Get module: if the bundle is empty (the key field is empty or missing), take the “new record” path; otherwise take the “exists” path.

    Can I query a data store by a non-key column? Not directly. “Search Records” lets you filter by any field, but it’s a full-table scan — Make reads every record and then applies the filter. This works fine for small stores but gets slow and expensive at scale. The better design is to set your key column to the value you’ll query most often, so you can use “Get a Record” directly.

    What happens when a data store is full? Make throws a “Data store is full” error on the next write attempt. The failing operation errors, the scenario logs it, and if incomplete execution handling is enabled, the bundle is parked. There’s no silent data loss — the error is explicit. Monitor your store sizes in the Data Stores panel and set alerts if a store is on a growth path.

    Do data stores count against my credit usage? The data store module itself counts credits like any other Make module — each time the Data Store module runs, it consumes one credit (or one credit per bundle for bundle-level operations). The data stored in the store does not consume credits; only the read/write operations do. See the companion article on Make operations vs. credits for the full credit model.

    Get the full Make reference

    The free Builder’s Companion Kit has the data store cheat sheet, a cost estimator so credits never surprise you, six importable starter blueprints, and the Production Readiness Checklist. Everything in one download — no fluff. Get the free kit →

    If you’re ready to start building, you can create a free Make account here and have your first scenario running today — the free plan is enough to learn on and test your first data store.

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

    Make 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:

    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.