The amr users cache log is a useful tool especially when using background (cron) cacheing.

Cache log example, where user master was updated (not meta). A Cache rebuild had been scheduled, but not yet run.

 The cron log

• shows key actions with latest at the top, so read from the bottom up.
• will show more messages if wp-debug is enabled
• does not keep a lot of history – it cleans up after itself.  It’s a testing tool primarily.
• will indicate runtimes
• will indicate batches of updates of the cache records.
• will list why a cache was initiated
  • master user update
  • user meta update
  • background request,
  • else  manual request

Example Screenshots

User meta update request:

• the green text showing the action that causes a request to rebuild cache
• the bolded text controlling background job that setups the cron jobs for each of the lists
• the italic text showing the completion of the cache rebuilds for each list.

User Meta Update causes cron cache rebuild

Change of settings and background run

• the change of setting is listed and the time that the next cron job will run
• the rebuilds of reports 1 and 2 have been scheduled but not yet run

Background request scheduled, preceded by some manual request, also some debug statements on memory

Cron jobs have been run for reports

An update of the previous image – the jobs have now been run.

Why use the cron log?

One can confuse oneself mightily if

• changing settings,  while background jobs are running, or
• on very large data bases if runs take a while
• if you have user update set, but no updates seem to happen (maybe your user updates are not actually to the wp user meta.)
• …

So take it easy – use the tools available.  A good cron manager plugin may also be helpful. There are many around. I like my cron manager plugin because you can reschedule any cron job, eg make them run immediately.  It’s included in developer memberships.