Operations
Each time a module performs an action, it uses an operation. For example, adding a row to your Google Sheet or getting data from your Gmail account, each uses one operation.
Understanding your operation usage is important because Make charges based on the total number of operations performed by the modules in your scenario. More modules and bundles processed in a scenario result in a higher number of operations.
If you exceed your monthly operation limit, your scenarios will be paused until the next usage reset. To resume your scenario immediately, you can purchase additional operations or you can enable the extra operations auto-purchasing to prevent your scenarios from pausing in the future. You can learn more about the available options below.
In addition to the number of operations, each plan gives you a certain amount of data that your scenarios can process during the usage period. You can find more information about your usage allowance here.
Every time a module in a scenario performs an action, it uses one operation. If a module outputs multiple bundles of information (like a List module returning multiple records), it makes the following module run once for each bundle, processing each record separately. The total number of used operations for a module equals the number of performed actions.
All the types of modules can use from one to many operations, depending on their place and function in the scenario:
- Trigger modules always use one operation regardless of whether they receive any data or not.
- Search modules use one operation to run, but can output multiple bundles. For example, the Google Sheets Search Row module will run once and use one operation, but it can return information about multiple rows after one run. Each row is a separate bundle of data.
- Action modules (Add, Update, Delete, etc.) use as many operations as many runs they need to make to process all the input data. If you have 10 rows returned by the Google Sheets Search Row module the next Delete Rows module will run 10 times to delete all the 10 rows and will use 10 operations.
- Aggregator modules take multiple bundles and combine them into one. The aggregator uses one operation for each aggregation. If the aggregator creates one array from your Google Sheets records, it will use just one operation.
- Iterator modules are opposite to the aggregator modules. Iterators take one array bundle and split it into multiple bundles as an output, so they use one operation for the entire array, but modules after them will receive more than one input.
There are a few exceptions of modules when Make does not use the operations:
In this senario, Make gets the list of the Top 10 songs of an artist you select, and adds it to the list of the songs you liked.
Once the execution of a scenario is completed, Make displays the number of operations performed by each module in the little white circle above the module.
In this example, the first Spotify module returned 10 songs and performed 1 operation while getting the information. Each song is returned as a bundle of information, so the next module has to work with 10 bundles.
The second Spotify module had to add each of the 10 songs to the playlist, requiring it to perform this action 10 times. As a result, the module processed 10 bundles and used 10 operations.
The run of this scenario required 11 operations in total.
In this example, Spotify limits each artist to 10 top songs. However, you can control the number of operations your scenario uses by restricting the number of results for Search and List action modules. For example, you can create a scenario that adds new songs from an artist to your playlist but limit the List module to return only 5 songs. This way, only 5 new songs are added per run instead of an entire album of 30 songs, saving operations. Additionally, you can use filters to process only specific bundles returned by modules. This ensures that only the bundles passing the filter are processed, consuming fewer operations.
In the example above you can see how to count operations for a scenario during one run. But it is also important to know how many operations your scenario is using in total.
Scheduling your scenario will make it consume operations every time it runs. For example, if your Spotify scenario is scheduled to run every hour, that would equal to 264 operations a day (11x24). If you schedule it to run every 5 minutes, it will consume 3168 operations per day (11x24x12). That's why it's important to schedule your scenario carefully. You can reduce the number of used operations by scheduling some scenario to run less frequently.
Every scenario run uses at least one operation because the trigger module needs to check for updates. Even when no new data is retrieved, these check runs still add to your total operation count, as the trigger uses an operation each time it checks according to the schedule. You can view all the check runs from the History tab in your scenario. If you don’t see them, ensure that the Hide check runs toggle is off.
You can also check how many operations your scenario has consumed in total without calculating anything. You can easily find this information in the list of scenarios or the scenario history.
When you open a list of scenarios, you can see how many operations each scenario has consumed under its name. If you hover over the number you can see the date when the count started (the beginning of the usage period).
For yearly subscriptions, the label displays the reset date, but the data represents an aggregated usage within the last 60 days.
To open the scenario execution history, click on the scenario from the list of scenarios. Under History on the right, you can see the number of operations consumed for each scenario run.
Similarly, you can switch to the History tab and see the number of consumed operations for each run there in a table format.
When a regular execution ends with a warning or error, an incomplete execution is created. Any attempts to fix it are tracked in the Incomplete Executions tab, with each attempt consuming operations. These operations add to the total used by the scenario and are included in the operations usage displayed in the list of scenarios, even though they aren't visible in the History tab. You can view the operations used to resolve an incomplete execution in the incomplete execution details. Note that, by default, the storage of incomplete executions is disabled, but you can enable it individually for each scenario.
While it is important to know how many operations each scenario consumes, it is also important to know how many operations your Organization and each Team within the Organization use. This can be easily checked from both Organization and Team dashboards.
To open the dashboard, click Organization or Team in the left-side navigation.
From the Organization dashboards it is also possible to see the limits you have according to your plan, how many operations were used during the current period, and to check the options of purchasing additional operations if needed.
When you run out of operations, your scenario will pause until additional operations are added or the next billing cycle begins. Incoming webhooks will be queued based on your available webhook storage and processed once your scenarios resume with the new operations. Additionally, scenarios that poll for data will search for available records since the last successful run.
If you are on the Enterprise plan, your scenarios will continue to run thanks to the operations overage protection. During this time, your CSM will contact you to resolve the issue and prevent any interruptions.
We'll notify you when you're approaching 75%, 90%, and 100% of your purchased operations. This way, you can ensure you have enough operations to meet your needs or take action to prevent your scenarios from pausing.
Here’s what you can do if you run out of operations before the next billing cycle:
- Purchase extra operations in bundles of 1,000 or 10,000 operations at the fixed price defined in your subscription. Extra operations work the same as pre-purchased operations and expire after the current billing period (monthly or yearly).
- Enable the auto-purchasing: once you use all 10,000 extra operations, Make auto-purchases 10,000 operations again. Make limits auto-purchasing to the number of operations in your subscription. For example, if your plan has 80,000 operations, auto-purchases can happen up to 8 times. Make charges you for the 10,000 operations based on your plan, plus a 30% surcharge. You can learn more about this option here .