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.