Reduce the risk of my Queueables to harm other async jobs

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.

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.

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.