Document how the module works, how it is initiated, etc

A specific question I had was whether it affected the system queue.

It's also unclear how the timing on the cron tasks listed on the settings page relates to automated_cron's timing, e.g. if the automated_cron interval is set to three hours, why do the cron settings indicate a cron task will run e.g. every fifteen minutes? This leads to confusion over how it will actually behave.

How about a deal? :)

I'll try to answer your questions and you help write the documentation?

* The module replaces the core queue service. When cron runs, it decides *what* runs, but ultimate_cron has no control over *when* cron runs.
* Drush commands do offer some extra flexibility, but in almost all cases, you just want to execute cron and let it do its job based on the configuration (Things get more complex when using channels but that's very rarely needed).
* Every time cron runs, each configured job is checked whether or not it needs to run again based on when it was last executed.
* In general, any non-trivial site should not use automated_cron but set up a separate cron definition to have cron executed reliably and frequently enough. I'd argue that any site that needs this module is by definition non-trivial.
* Whatever way is used to execute cron, it should run at least as often as the most frequent cron definition. If your most frequent one needs to run every 5 minutes, then execute cron every 5 minutes, and so on. This can be confusing, but all we can do is document this. The module doesn't know how often and when and how cron will be initiated. The automated cron setting just means that core will call it when a visitor accesses a non-cached page after at least as much time as configured has passed. If everything is cached or nobody visits the site, cron will not run. So again, don't use it.
* By default, queues are processed every time cron runs, which in most cases is enough. The only overhead is a query/call to the queue backend for each queue to check if there's anything that needs to be done. There is an optional setting that will expose each queue as its own job and allows for more fine tuning.

Bonus answer that people keep struggling with is how to define extra/multiple cron jobs for a single module. The module auto-discovers cron jobs on install, but if a module adds or removes a cron hook or if the queues are exposed as jobs, the discover process needs to be started. Extra jobs need to be defined as config entities, through the usual means of getting config into the active storage. default config for a not-yet installed module, an update function, site config import. Somehow quite a few people struggle with that part, but it's exactly like all other configuration.

Also, I've created 📌 Replace hook_cron() with a more modern approach Needs work which would solve the primary use case that people have for using this module in core.

📌 Replace README.txt with README.md RTBC should be committed first, just to make it easier.

This sits on top of the README.md merge request. It needs some further work, but it's a start.

Here are a guide that could be useful: https://befused.com/drupal/ultimate-cron/

That post is pretty good I think, I linked it from the project page now. Maybe it could be moved to a drupal.org documentation page, so it doesn't get lost.

The blocker is in, setting to needs work for the missing parts.

I started adding some more details.

This adds a troubleshooting section.

Extended and cleanup up some things around the queue system, it has nothing to do with the System cleanup job and most users really don't need the advanced features there.

Merged.

Automatically closed - issue fixed for 2 weeks with no activity.