Elastic Limits for Async Apex Jobs in Winter '27

Tweet

Image generated by ChatGPT 5.6 Sol based on a prompt from Bob Buzzard

Introduction

The Summer '26 Salesforce release introduced the beta of elastic limits for asynchronous Apex Queueable and Future methods. It stays in beta in Winter '27, but extends the capability to Batch jobs. 

If you aren't familiar with this feature, it is essentially a safety net for when your asynchronous processing takes a hot turn and you suddenly find your system executing more jobs than governor limits allow. 

What's in a number?

Without elastic limits, as soon as you exceed the standard limit of

   max(250k, 200*applicable user licenses)

attempts to enqueue^* additional jobs fail. 

With elastic limits you can continue to enqueue^* jobs up to the additional elastic limit of

   min(2m, standard limit)

This isn't simply a doubling of the limit though - while that would be very cool for us, it would likely send a few Salesforce data centres into meltdown! Additional jobs enqueued^* over the standard limit are subject to slowdown. Active job processing is throttled, and Batch jobs are limited to one active job at a time. 

How slow is slow?

Salesforce doesn't publish details of the throttling, which doesn't surprise me. This feature should be thought of as a safety net that makes use of spare capacity to help you avoid losing work. If the throttling algorithm were to be published, I'm pretty sure it would be widely misinterpreted as an SLA, with capacity planning based on behaviour that isn't contractual. 

The main thing to remember is that capacity is guaranteed, obviously up to the elastic limit, but throughput isn't. You can continue to enqueue^* jobs, but you can't predict when they will execute, or when they will complete their processing. To be fair, if we take the Salesforce docs at their word, then this is no different to regular asynchronous processing:

Because many customers share available resources on each Salesforce instance, the exact execution timing of asynchronous requests cannot be predicted or guaranteed.

For the vast majority of scenarios this is fine. My experience is there are rarely delays (outside of service issues), and processing completing slightly later than expected typically has little to no business impact. If processing is really time-sensitive and mission-critical, we all know it should happen outside of Salesforce on infrastructure with guarantees. 

How can I tell I've hit the elastic?

There's a couple of ways to achieve this. 

The first is through the time-honoured mechanism of looking at a web page, the Apex Jobs setup page in this case:

The second, and probably more useful for developers, is using the OrgLimit class:

   Map<String,System.OrgLimit> limitsMap = OrgLimits.getMap();

   // -- Standard Limits --
   System.OrgLimit asyncApexDailyLimit = limitsMap.get('DailyAsyncApexExecutions');

   // Total enqueued in last 24 hours
   Integer usedLimit=asyncApexDailyLimit.getValue();

   // Daily limit
   Integer dailyLimit=asyncApexDailyLimit.getLimit();


   // -- Elastic Limits --
   System.OrgLimit asyncApexElasticLimit = limitsMap.get('DailyAsyncApexElasticExecutions');

   // Total enqueued in last 24 hours - same as asyncApexDailyLimit.getValue()
   Integer elasticUsedLimit=asyncApexElasticLimit.getValue(); 

   // Elastic limit 
   Integer elasticDailyLimit=asyncApexElasticLimit.getLimit();

There's a couple of things to bear in mind here though:

1. If you haven't enabled elastic limits, executing   
      limitsMap.get('DailyAsyncApexElasticExecutions')
   will return null
   
   
2. For non-production orgs the standard + elastic limit is the same as the standard limit - only production orgs have additional capacity

No elastic in the schedule?

The eagle-eyed reader will have noticed that scheduled Apex is conspicuous by its absence. While the timeline so far might suggest it is coming in the next release, my own view is that this is rightly excluded. The elastic limit swaps timeliness for additional capacity - the benefit is the processing will complete eventually. Scheduled Apex requires timeliness - typically we schedule jobs to run at a particular time because that is when we need the processing to happen. 

Of course there are times when scheduled jobs just have to run at some point during a day, but to schedule them you have to choose a specific time. These jobs are candidates for elastic limits, but the problem is there's no way that Salesforce can know this. Luckily these jobs can just hand off to Queueable, Batch, or even Future if you are feeling retro, and take full advantage of the elastic capacity (such as it is).

^*Enqueued or executed?

That's a great question, and one that I don't really have an answer to. The Salesforce docs seem to switch between executing and enqueuing jobs, and the Apex Jobs page throws processed into the mix, so I've continued with that. I assume that you won't be able to enqueue infinite jobs and there will only be exceptions when the executions exceed the elastic limit, but I'm not seeing that clearly called out in the docs. Remember that this is a beta feature - I'm sure by the time it becomes generally available the docs will have tightened up a little.

Conclusion

The main takeaway is that two times the asynchronous allowance doesn't mean two times the compute, or anything like it. This is a nice gesture from Salesforce that can really help with resilience, but if you are regularly exceeding the standard limit then it's worth investigating why and what you can do about it, even if that means offloading some processing elsewhere.

More Information

• Winter '27 Release Notes for this feature
• Apex Developer Guide docs for this feature
• Increased Apex Heap Size in Winter '27
• Winter '27 for Developers slide deck

Follow on LinkedIn