Make.com Operations Explained: Understanding the Pricing Model

Understanding Make.com Operations: Master the Pricing Model

Make.com's operations-based pricing confuses many newcomers. Unlike Zapier's per-task model, Make.com charges based on operations—the individual processing steps within your scenarios. Understanding this model helps you optimize costs and avoid billing surprises.

What is an Operation?

An operation occurs each time a module in your scenario processes data. Every node (module) that executes counts as one operation.

Simple Example:

A scenario with 3 modules (Trigger → Transform → Action) uses 3 operations per execution.

Key Points:

• Each module = 1 operation when it runs
• Modules that don't run (filtered out) = 0 operations
• Routers and filters themselves don't count
• Failed modules still consume operations

Operations vs Zapier Tasks

How Operations Are Counted

Scenario 1: Basic Workflow

[Gmail Trigger] → [Slack Message] → [Google Sheets Row]
     1 op              1 op              1 op
                                    = 3 operations total

Scenario 2: With Router (Branching)

[Webhook] → [Router] → [Path A: Slack] → [Sheets]
   1 op       0 ops        1 op           1 op
                     → [Path B: Email]
                           1 op

If Path A runs: 3 operations. If Path B runs: 2 operations. Router itself is free.

Scenario 3: With Iterator (Loops)

[Trigger: 1 record with 5 items] → [Iterator] → [Process Each] → [Aggregator]
          1 op                       1 op      5 ops (once per item)   1 op
                                                            = 8 operations

Iterators multiply operations—each item in an array triggers the downstream modules once.

What Counts as Operations

✅ Counts:

• Any module that executes (apps, HTTP, tools)
• Set Variable, Text Aggregator, Array Aggregator
• Each iteration of a loop
• Failed operations (errors still count)
• Sleep/delay modules

❌ Doesn't Count:

• Routers (branching logic)
• Filters (conditions between modules)
• Modules that are skipped due to filters
• Scenario activation/deactivation

Pricing Tiers Explained

Additional operations can be purchased. Higher tiers include more features (execution history, team collaboration) rather than just more operations.

Strategies to Reduce Operations

1. Use Filters Aggressively

Place filters early in your scenario to stop processing before hitting expensive modules.

2. Batch Processing

Instead of processing one item at a time, batch items together to reduce trigger operations.

3. Optimize Iterators

Be careful with arrays—10 items × 5 modules = 50 operations. Aggregate before iteration when possible.

4. Consolidate Scenarios

Multiple small scenarios may use more operations than one well-designed scenario.

5. Use HTTP When Appropriate

One HTTP module calling an API endpoint = 1 operation, versus a native integration that might use multiple modules.

Estimating Your Monthly Usage

Calculate expected operations:

1. Count modules in each scenario
2. Estimate monthly trigger frequency
3. Account for loops and branching
4. Add buffer for errors and testing

Example Calculation:

Scenario A: 4 modules × 100 runs/month = 400 ops
Scenario B: 6 modules × 50 runs/month = 300 ops
Scenario C: 3 modules × 500 runs/month = 1,500 ops
Testing/errors buffer (10%) = 220 ops
─────────────────────────────────────────────
Total: 2,420 operations/month (Core plan: $9)

Monitoring Your Usage

Make.com provides usage tracking:

• Dashboard: See current month's operation consumption
• Scenario History: Operations used per execution
• Usage Reports: Breakdown by scenario and time period
• Alerts: Set up notifications before hitting limits

Common Operation Traps

1. Webhook Floods

External systems sending excessive webhook calls can burn through operations. Implement rate limiting or deduplication.

2. Polling Frequency

Scenarios polling every minute use more operations than those polling hourly. Match frequency to actual needs.

3. Unconstrained Loops

Iterating over large arrays without limits can consume thousands of operations unexpectedly.

4. Error Retry Loops

Automatic retries on errors still consume operations. Configure retry limits appropriately.

Operations vs Execution Time

Note: Make.com also limits execution time per operation (varies by plan). Long-running operations may timeout regardless of operation count.

Need Help Optimizing?

Our Make.com specialists design efficient scenarios that minimize operations while maximizing results.

We'll analyze your workflows and recommend optimizations that can significantly reduce your Make.com costs. Contact us for an efficiency audit.