Parallel Capacity

your organization can run a limited number of scenario runs at the same time this page explains how that capacity works, how to monitor it on the parallel capacity dashboard, what happens when you reach your limit, and how to reduce peak load parallel capacity is about how many runs happen at the same time and how many resources they consume it's not about how many runs you make in total, how many credits they use, or how long they take how parallel capacity works every scenario run takes capacity while it's running, and releases it as soon as it finishes think of it like parking spaces your organization has a fixed number of spaces, and a car has to leave before another one can park capacity is measured in processing units (pus) a typical run takes one pu runs that process large amounts of data use more memory, and those runs take more than one pu for the whole time they run two scenarios that run the same number of times can use different amounts of your capacity your limit applies at the organization level, so all teams and all scenarios in the organization share the same pool find the parallel capacity dashboard go to organization settings , open dashboard , and select parallel capacity the dashboard shows the processing units your scenario runs use over time, so you can view when you hit peak load and which scenarios drive it how to read the chart the chart shows your capacity usage as stacked bars over time each stacked bar is one point in time, and each color in the bar is a different scenario the height of the bar is the total processing units in use at that moment hover over a bar to view the exact number of processing units a scenario used at that time use the legend below the chart to identify scenarios, and the search field to filter to the ones you care about drag the handles on the slider below the chart to zoom into a shorter period, or to zoom out across several days drag the slider selection or the chart to move backward and forward in time full capacity and fit to usage the y axis scale control changes what the chart is measured against full capacity shows the axis up to your organization's limit, so you can view how much headroom you have left fit to usage scales the axis to your actual usage, which makes smaller peaks easier to read when your usage reaches the top of the chart in full capacity view, a line appears at the limit bars that touch that line mean your organization was at full capacity, and make delayed or rejected new runs at that moment spotting patterns over time zoom out to several days to spot recurring peaks, for example a nightly sync or a weekly report that consistently pushes you to your limit these scenarios are usually the best candidates for rescheduling what happens when you reach your limit in many cases you see a delay rather than an error the behavior depends on the type of scenario type of scenario is data queued? what happens instant, with a webhook response module, or on demand scenarios such as subscenarios no make responds to the caller with status 429 and the message too many executions running in parallel on organization level if the caller doesn't retry, make doesn't process the data for webhooks, make stores an error log instant, without a webhook response module yes make queues incoming data and processes it as capacity becomes available no error, though you may notice delays scheduled no make delays the next scheduled run until capacity is available the delays can be longer than for instant scenarios, but this doesn't cause an error make can't queue responsive scenarios without changing the behavior you designed into the scenario, so it tells the caller to retry later instead of failing silently if one of your scenarios calls another scenario that can be rate limited, add error handling to the calling scenario the simplest option is to enable incomplete executions docid 6zznn7v35herrcjfccp9q and retry manually, or to pair them with an error handling route that uses retry error handler docid\ cptwi8yi45zl3m5slzjnv to resolve failed runs automatically scenario rate limits you can set a maximum number of runs per minute for any instant scenario in its schedule settings docid 8rwfo krohjlepg4qhx3 a rate limit protects a third party api that has its own rate limits, and keeps a high volume scenario from consuming your whole organization's capacity when you exceed this rate limit, make behaves the same way as when you reach your organization's parallel capacity, but with a different message responsive scenarios receive status 429 with too many requests for scenario , and non responsive instant scenarios queue the data instead if a scenario is unexpectedly slow to collect new data, check its schedule settings first a rate limit set some time ago is a common cause reduce peak load if you regularly reach your limit, the goal is to spread the same work across a longer period rather than running everything at once start with two changes that don't require reworking your scenario logic rate limit your less time sensitive scenarios so your critical ones have more headroom stagger your triggers by processing data in smaller batches, or by adding a short delay between them memory runs that use more memory take more processing units, so trimming the data your scenario carries has a direct effect on your capacity start by avoiding repeated data a common example is selecting all values in an aggregator when you only need a few of them, which means every bundle carries fields you never use if your scenario is already lean, process your data in smaller batches instead, or spread its schedule so it doesn't consume all your processing units at once processing power large iterations and aggregations are convenient, but they can use a lot of processing power and memory they often slow a scenario down more than necessary for the result you're after, and a slower run holds capacity for longer for complex data transformations, try replacing a long iterate and aggregate chain with the make code app a small script is often faster and uses fewer resources and credits than the equivalent chain of modules subscenarios if a subscenario takes too many processing units, batch the data you send to it instead of one run per item, send a group of items to a single run consider the trade off each run takes longer and may take more processing units, because it handles more data and therefore uses more memory and processing power in exchange, you get a much lower overall number of runs, which usually causes the peaks that push you toward your limit another approach is to move some or all of the subscenario logic into the parent scenario the parent consumes more processing power and memory, and its runs take longer, but this change reduces your overall number of runs webhooks non responsive webhooks for scenarios that don't need to react instantly, switch to a scheduled webhook make collects the data as it arrives and processes it on your schedule, which moves the work away from your busiest moments responsive webhooks if your scenario needs to respond to a webhook, make it as quick as possible the longer the run takes, the longer it holds capacity, and make can't queue responsive scenarios when you reach your limit if you need to do more work after responding, save the webhook data to a data store and process it later in batches through a separate scenario this approach keeps your response fast and helps you avoid limits when a lot of data arrives during a peak of activity check your work use the parallel capacity dashboard to confirm the change worked after you reschedule, batch, or rate limit a scenario, the same period shows a lower, flatter set of bars