How to Use Make Without Draining Credits (2026)

Make bills you per module: every step a scenario runs costs a credit. That meter, not the canvas, is what this guide is organized around: every setup choice below is weighed by what it does to your credit spend. A workflow that loops over 40 line items costs far more than one that fires once, and a trigger set to poll every few minutes spends credits around the clock whether or not anything changed. Make wires several apps together and moves data between them without much code: you build a workflow on a visual canvas, drop in one app step at a time, and connect them so a new row in a spreadsheet fires off a Slack message, a follow-up email, or a database update. The wiring is the easy part. Managing the credits is the actual work, and every decision about whether to branch, filter, or loop is really a decision about how many the scenario spends. Get the logic right and it runs clean; get it wrong and it quietly drains your monthly allowance.

Place the tool honestly before you commit to it. This is heavier than simple one-step automators like Zapier, and it asks more of you in return. If all you need is a dead-simple linear trigger with almost no learning curve, Make is the wrong tool for the job, and the Make alternatives page points to lighter ones. Multi-branch work at moderate volume is the job it fits: the kind of scenario with routers splitting traffic, iterators walking through arrays, and error handlers catching the calls that fail.

What the free tier buys you, and where its walls sit

Register at make.com with just an email; a card is never requested. The Free plan runs $0 and covers 1,000 credits a month, 2 active scenarios, and access to the 3,000+ apps Make advertises. Its walls are close enough that you meet them fast: the shortest interval between scheduled runs is 15 minutes, a single run cannot execute longer than 5 minutes, execution logs are kept for 7 days, and data transfer tops out at 512 MB. Those limits decide what the tier can do. With 1,000 credits and two active scenarios you can build a real automation end to end and watch it run, but the 15-minute floor and 5-minute execution ceiling stall anything time-sensitive, so it's a proving ground rather than somewhere a business runs live work.

Paid plans lift most of those walls in one move: unlimited active scenarios, a 1-minute minimum interval, a 40-minute execution ceiling, 30-day logs, and access to the Make API. Pricing starts at roughly $12 a month, or about $9 a month billed annually, and scales with a credits slider. The pricing page is a live slider and the tier structure has been shifting through 2026, so check make.com/en/pricing for today's exact numbers rather than a figure copied from a blog. The practical read: stay on Free while you are learning what your scenarios cost, and move up once you know the credit math for the work you intend to run.

Five words the canvas runs on, and the sixth that costs money

The interface leans on a small vocabulary everywhere, and mixing the terms up is where early confusion comes from. A scenario is the whole workflow you build. A module is one step inside it, shown as a circle on the canvas. The trigger is the first module, the thing that kicks the scenario off. An action is every module after the trigger. A connection is the authenticated link between Make and an outside app like Google or Slack, created once and reused after that.

The sixth term is the one that shows up on the invoice: credits. Make bills in credits, renamed from "operations" in August 2025 with existing operations converted one-to-one, and most module actions cost one credit each. Hold that model in your head from the start, because it changes how you read every decision below. Triggers, filters, and each pass through a loop all spend credits, not just the final action. People carry over a mental model from simpler tools where only the last step counts, then get startled when a trigger, a search, and a filter each bill. A failed run still charges for the steps it already ran.

Filter, branch, or loop: the choice that sets your credit burn

This is the fork that decides whether a scenario is cheap or expensive, so make it deliberately rather than by habit.

A filter sits on the link between two modules and only lets bundles through when a condition is met, for example only notify when a row is complete. Filters cut wasted downstream work, but here is the Make-specific catch: a filter spends a credit even when it stops the flow, unlike some cheaper tools where filters are free. That charge is what drives the rule. Place filters as early as you can, so they prune expensive modules before those modules ever run.

A router splits the scenario into parallel branches, useful when one trigger needs to fan out into several different actions.

An iterator breaks an array into separate bundles so downstream modules run once per item, and an aggregator recombines them into one output. Iterators are where cost multiplies without warning: 12 line items through a 4-module loop bills 48 credits, not 4. Use an iterator only when you need per-item processing, not by default, because the credit count scales with the length of every array you feed it.

The through-line across all three: each of these is a lever on how many operations run, and each operation is a credit. The cheapest scenario is the one that does the least work per trigger, so filter early, branch only when the paths truly differ, and loop only when per-item handling is the actual requirement.

Building the reference scenario, one decision at a time

Make's own tutorial starts before the builder, and skipping that planning step is where beginners lose the most time. Decide three things on paper first: what triggers the scenario, what data needs processing, and what should happen at the end. The example Make documents, and a solid one to copy, is watching a Google Sheet for new prospect rows and posting a Slack notification to a sales channel. Trigger is a new row, data is the prospect's details, outcome is a message in the right channel. Confirm the apps exist in Make and that you hold the access to use them, since Slack posting needs workspace rights and watching a sheet needs access to that specific spreadsheet. Sorting permissions now beats hitting a wall mid-build.

Prep the source and destination by hand before you touch the canvas. In Slack, create a public channel named something like "sales team". In Google Sheets, start a spreadsheet, rename it "prospects", add columns for first name, last name, country, email, phone number, and details, then drop in one sample row. Keep that sheet open in a second browser tab, because you will point Make at it in a moment.

On the canvas, click "+ Create a new scenario" in the top-right. Click "New scenario" in the top-left to rename it to something you will recognize later, like "new prospect notification", and hit the save icon on the toolbar. A vague name gets confusing once you have built a handful. Add the trigger by clicking the giant plus in the center, searching for Google Sheets, and picking "Watch new rows", the module that fires whenever a row lands. The first time you use an app, Make asks you to create a connection, which opens the app's own sign-in popup where you grant access and name the connection. After that you reuse it without authorizing again. Configure the trigger to point at the "prospects" spreadsheet, the sheet inside it, and which rows to watch. This first module is the whole spine of the scenario, so it is worth a second look before moving on.

Add the action by clicking the small circle on the right edge of the trigger, searching for Slack, and picking "Create a Message". Mapping the data is the core skill here. Click into the Slack message field and a data tree appears showing the output from "Google Sheets > Watch new rows". Drag values into the field, or click one to insert it, and combine several in a single field. A template like "New prospect added! [name] [email] [country] [phone] [details]" works well, each bracket replaced by a mapped value. Built-in functions can transform values as you map them, for example trimming whitespace or reformatting a date. Save the module, then the whole scenario.

Test before you trust, and start the trigger from the right place

Never activate a scenario you have not run at least once. Click "Run once" in the toolbar to fire it a single time. Operation bubbles pop up above each module showing how many credits that step consumed, and clicking a bubble opens the exact data flowing out of it. That is how you confirm the trigger picked up the row and the mapped values landed where you intended, and it is also how you learn what the scenario costs before it runs unattended a few thousand times.

The first run only sees brand-new rows by default. To reprocess rows that already exist, right-click the trigger, choose "Choose where to start", pick "All", and save. Without a real sample bundle to map from, downstream fields come up empty, which is one of the most common reasons a new scenario looks broken when it is not. Run a full end-to-end pass before you rely on it: add a couple of fresh rows, hit "Run once" again, and watch execution move module by module, confirming the trigger fired, any filter allowed or blocked correctly, and the Slack message arrived.

One safety habit belongs here. To test a scenario that has a real-world side effect, drop in an impossible filter, a condition that can never pass, ahead of any module that sends something, so a stray "Run once" does not fire actual Slack messages or emails while you build. Pull the filter once the logic checks out.

Scheduling: the single knob that moves your invoice most

Scheduling a scenario and turning it on are two separate actions, and Make warns you about this directly. Click the schedule control in the toolbar, which shows the current cadence, by default "every 15 minutes", to open the scheduling panel. You can run at regular intervals, once, daily, on set days, or on demand. Free plans hold a 15-minute floor, paid plans go down to 1 minute. Save the schedule, then click "Activate scenario" or flip the on/off toggle near the name. Configuring a schedule does not switch the scenario on by itself.

Interval choice drives your bill more than any other setting, so pick it deliberately. Make's own math: a scenario polling every 5 minutes burns 288 credits a day, while one running hourly uses 24. On the Free plan's 1,000 credits, an aggressive schedule on a polling trigger is the fastest way to run dry, because a polling trigger spends a credit on every check whether or not new data appeared. Where an app supports an instant webhook trigger, prefer it over polling, since a webhook fires only when there is something real to process. And if you activated a scenario only to test it, switch it back off afterward, because a dozen half-built test scenarios all polling in the background quietly eats your monthly allowance.

Two more billing decisions sit next to scheduling. First, overage does not fail safe. By default Make does not stop when you hit your quota, it auto-purchases extra credits and bills you, and since November 2025 those extra credits carry a 25% markup over your in-plan rate. That is fine if you meant to scale and a nasty first invoice if you did not, so set the behavior you want in plan settings rather than discovering the default the hard way. Second, mismatched data types cause a surprising share of mid-run errors: sending a string where a module expects a number or a date is a top cause. Normalize values early, phone numbers to a consistent format, dates to a single standard, text trimmed and lowercased, so a later module does not choke.

When a step fails: the five directives, and which one fits

Error handling is what makes a scenario resilient rather than fragile, and it is worth learning early. Right-click a module and add an error handler, then pick from Make's five directives. Ignore skips the failed step and continues. Resume continues with a substitute value. Commit stops and marks the run successful. Rollback stops and reverts what it can. Break sends the run to an Incomplete Executions queue to retry later. For a flaky third-party API, Break paired with retries handles transient failures without losing data. These control modules cost no credits, so there is no billing reason to skip them.

Moving cost off Make's meter

Some work is cheaper to keep off the credit counter entirely. AI modules charge variable credits by tokens and file size, which makes them the least predictable line on the bill. Connecting your own LLM key through an HTTP request, allowed on paid plans, can drop an AI step toward roughly one credit per call and move the token cost onto the provider's bill instead, where it is easier to track. That HTTP module matters for another reason too: it sends requests to any public REST API, so it reaches a service that has no dedicated connector. It is more setup than a native app, since you handle the authentication and request format yourself, but it is why Make can wire up almost anything with an API.

Keep the structure lean while you are at it. The canvas clutters quickly once you have nested routers and eight or ten connected apps in one build, and a giant scenario breaks more and debugs harder. Split logic across several focused scenarios, use Data Stores, Make's built-in database, to hold state between runs instead of paying for an external one, and name and folder everything from day one. Connections you build are reusable across new scenarios, and the template gallery lets a future automation start from a ready-made blueprint, so you plug in your own connections and mapping rather than wiring from a blank canvas.

FAQ

How do you use Make for free?

Registering at make.com takes only an email, and no card is asked for. The Free tier comes with 1,000 credits a month, 2 active scenarios, a 15-minute minimum run interval, a 5-minute execution ceiling, 7-day logs, and access to the 3,000+ apps Make advertises. It's enough to build and test real automations end to end, but between the 1,000-credit cap, the two active scenarios, and the 15-minute floor between runs, nothing time-sensitive holds up, so live work belongs on a paid plan.

What's the difference between a scenario and a module?

A scenario is the whole automated workflow you build on the canvas. A module is one step inside it, shown as a circle, such as "Watch new rows" or "Create a Message". Modules connect in sequence: the first one is the trigger that starts the scenario, and every module after it is an action. Most module actions cost one credit each time they run.

Why is my Make credit usage higher than expected?

Almost every step bills a credit, not just the final action. Triggers, searches, and filters all count, a filter charges even when it stops the flow, and a polling trigger spends a credit on every check whether or not new data appeared. Loops are the big one: an iterator bills per item, so 12 items through a 4-module loop costs 48 credits. A too-frequent schedule on a polling trigger is usually the culprit behind a runaway bill.

Can Make connect to an app that isn't in its library?

Yes. Alongside its native app catalog, Make includes an HTTP module that sends requests to any public REST API, so you can reach a service that has no dedicated connector. It's more setup than a native app, since you handle the authentication and request format yourself, but it's the reason Make can wire up almost anything with an API.