I know a specific org can enqueue up to 250,000 async jobs per 24h period in an org.

My app uses a few Queueable jobs on nearly every user transaction to send Usage Metrics to another server so this sums up. It's not a problem if some of them fail or don't run because the 24.h limit is reached.

But how can I decrease the risk for other async jobs?

  • Enqueue myself at night (Can I keep my jobs in pending?)
  • Use Flex Queue priorities (Is this already GA?)

3 Answers 3


I know I'm a bit late to the party, but I had a somewhat similar requirement.

The solution I came up with is similar to what others suggested, but instead of a Custom Object/Setting/etc. I used Platform Events. You could use Platform Events to create a 'pre-processing job queue' to be handled as you see fit.

Possible advantages:

  • Records are transient, meaning they are (basically) deleted after the transaction completes
  • Records are processed in their own transaction asynchronously
    • Note that the running user in a transaction is the Automated Process user, which is pretty cool, but could has consequences
  • No UI, so users can't peruse the data they don't really need to see, and also reduces object clutter

I've acquired a bit of a bias against scheduled batches. So when I can find ways to do the work on an as-needed basis, I try to push myself in that direction.


This is just a thought, but say you have Accounts, Contacts, Leads(whatever your objects are) and everytime one of these records qualify for changes (whatever that may be) you can create a new record in a custom object.

Let's call the object something like Service Transactions ..", so now rather than having your queueable fire every single time an Account,Contact .. etc qualifies for a queueable job you will actually just be inserting a new record into the Service Transaction table, now when you insert the record into the service transaction you will essentially only need the ID, and maybe a success or failure flag.

By inserting the ID with that Service Transaction you will now be able to build the data that you need to send out.

You can schedule the queueable(I think, you may have to get creative) to fire whenever you want, maybe end of day or middle of the night. This is just an idea..

If there is a concern about the strain that will be put on the org by the async jobs this cannot be real time.

  • 1
    I was thinking the same but custom settings. The obvious solution to reduce volume is batching the callouts. Can't upvote for a few mor minutes yet.
    – Adrian Larson
    Commented Feb 8, 2017 at 23:56
  • 1
    A Scheduleable batch job (or a batch class scheduled by some other means) would seem like a better candidate for this than Queueable, since it will scale better with more transactions. Depending on the API, you may even be able to batch the callouts with more than one record at a time. Commented Feb 8, 2017 at 23:58
  • @IllusiveBrian I think he's trying to chain jobs which you can't do from a batch, but I was thinking that also
    – EricSSH
    Commented Feb 9, 2017 at 0:01
  • Who says you can't chain batches?
    – Adrian Larson
    Commented Feb 9, 2017 at 0:03
  • 1
    You can straight up put Database.executeBatch(this) in the finish method. You probably want some mechanism to turn it off though if you want any hope of a sane testing pattern. I also sometimes use system.scheduleBatch(this, 15) as it's easier to pull off than "suicide scheduling" in my limited attempts so far.
    – Adrian Larson
    Commented Feb 9, 2017 at 0:07

For your particular case, EricSSH's answer is probably the best option. However, here are some answers for your question:

  1. You can query the ApexAsyncJob object to query asynchronous operations, though I cannot seem to find a way to specify 24 hours in SOQL. Additionally, this will run into the 50000 row limit on SOQL results.
  2. Eventually, the limits class appears to be slated to have getAsyncCalls and getLimitAsyncCalls functions which will return the number of async calls made in the last 24 hours and the organization's limit on async calls in 24 hours, assuming they follow the naming convention of the rest of the class.
  • +1 one to that because there is always more than one way, if you can quantify how many async jobs will actually run you may be able to also create a buffer so you can stop your server metrics from sending by using Brians idea with the limits. Granted I don't think it would be a great idea to create an artificial buffer but who knows
    – EricSSH
    Commented Feb 9, 2017 at 3:55

You must log in to answer this question.

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