In my sandbox environment, I have a batch job that invokes itself when it's done - it watches for records in a "actions" table, and executes them, so when the table is empty, it basically does no work. Normally, this batch job 20-30 times a minute, but in the last few days, it's closer to once a minute, and has a 5-10 minute delay a time or two an hour. Usually, when one execution of the job scheduled another, it'd go to 'Queued' quickly, but in the last few days, it spends a while in 'Holding' first.

Is this delay in processing batch jobs just an indication that the Salesforce platform is overloaded and jobs from my sandbox are de-prioritized? A misconfiguration in my sandbox? Is there a way I can see something from Salesforce to indicate why these jobs are running so much more slowly?

If this is just a temporary-overload issue, I can live with it, but I'm worried that there's a fundamental issue with this approach and I may need to look at other options, as in production, I'd like this job to be firing frequently enough that I can process many actions a minute (I can only process one action per batch, as I need almost all of the DML limit since I have to upsert many tables).

Edit: Further investigation indicated some of our jobs would take 5-10 minutes between CreatedDate and CompletedDate in ApexAsyncJob during the time we saw few jobs executed, even though the processed 0 records.

1 Answer 1


Executing a batch 20-30 times a minute is a really bad idea; every batch execution consumes a minimum of 3 asynchronous operations (one for start, one for execute and one for finish, with more if the data must be processed in multiple chunks - an extra async operation per additional call to the execute method).

Now if you consider you only have a baseline of 250000 async operations per day (as covered in the governor limits documentation), and then realize you have 1440 minutes in a day, this one batch is consuming up to around 129600 (1440 * 30 * 3) of your async operations for your org. Then consider you may have future methods, other batches and queueables running too, your could easily hit you limits before 24 hours is up.

I am wondering if Salesforce is throttling your org because you are making too many async calls.

Given your description, I wonder if you should be using a Queueable to try to reduce the number of async executions, though you will have to occasionally switch to using a future method to break the chaining since Salesforce limit the "depth" of chaining for queueables. An alternative is to implement something like what we call an "adaptive batch" - take a look at this answer for more details.

UPDATE: As per sfdcfox's handy comments, you can view the current limits using one of these approaches:

  • sfdx force:limits:api:display

  • workbench REST explorer with /services/data/v48.0/limits/

In both cases look for the daily async apex executions detail.

  • 1
    Yep near certain they are throttling.
    – Adrian Larson
    Commented Apr 16, 2020 at 16:34
  • This was a great answer around how throttling works, and is worth a look to understand why so many batch executions will hurt your performance: salesforce.stackexchange.com/questions/166204/… Commented Apr 16, 2020 at 17:24
  • Is there somewhere we can see what our current status is re: async govenor limits? Setup-Environments-System Overview doesn't have anything about async calls, and searching for 'async', 'limit' and 'governor' doesn't show any items in setup that look useful. Commented Apr 16, 2020 at 18:35
  • You can see your limits with an API call. In DX, it's sfdx force:limits:api:display, and has a line like DailyAsyncApexExecutions 249976 250000 (available, total).
    – sfdcfox
    Commented Apr 16, 2020 at 19:22
  • If you use the workbench, the REST Explorer /services/data/v48.0/limits/ will get you the same output, but in JSON, so a bit more annoying to read.
    – sfdcfox
    Commented Apr 16, 2020 at 19:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .