Thanks guys! Yeah it's a weird issue for sure and likely very rare, so it's probably not a big deal. If it helps for reproducing it, here's a few notes:
27 apps installed at the time of backup/restore
Backup & Restore used tgz format with OVH Object Storage in BHS region
Backup from a LunaNode m.8 model in Toronto region
Restored onto OVH b2-7 model (though since upgraded to b2-15) in BHS3 region
LunaNode instance (source) was running Ubuntu 18.04 at backup time, and OVH instance (target) was running Ubuntu 20.04 at the time of restore.
When I restored, I very nearly ran out of disk space on the included disk, leaving only ~ 1.5 GB of space remaining.
When restoring initially, it failed to restore because of the issue I reported earlier, though doubtful this is a root cause. Immediately moved the boxdata to external disk afterwards though, so plenty of space free soon after the restore was done once I moved boxdata off (20 GB in emails alone so it takes up a lot of space).
Hopefully those notes above help in some small way. No worries though if you can't reproduce it, I imagine it's a very rare scenario and could have even been completely unique to me somehow. Hopefully others can chime in though if they experienced anything similar where cron wouldn't run at all (whether a restore involved or not, as I'm still not 100% certain it had to do with the restore though I presume it did).
If you set it to 5 then WP site check is complaining that there are missed events. Because either WP or plugins can create 1 minute tasks.
Yes, cron scheduled Wordpress can be scheduled down to the minute. But they're expected to be missed. The default WP-Cron interval is "whenever the next person visits the site, run all the scheduled events that are in the past and haven't been run" (the one that Cloudron rightfully uses the WP-CLI and disables the native WP-Cron). That's pretty horrible, but that's what Wordpress installs expect the environment to be at default. So, the WP Site Check says that's notable, that wp-crons don't get run at the minute they're specified?
If the WP Health Status Page actually says that, then Wordpress devs clearly think 1 minute (or a hugely popular site) is the best interval.
@girish A fresh install already has it set to "No"? Interesting, I don't recall ever setting mine to "Yes", but I guess I did. Thank you for confirming, seems it's okay then if it's set to "No" by default and the cronjob is doing it automatically.
There's a bunch of plugins like WP Crontrol, Advanced cron, Simple cron. You can use them to setup a custom pattern and call a custom function. Your PHP function can just shell exec your script (or maybe you can even write PHP depending on your use case).
As others said, usually the cron job is part of the app itself. If for some reason you want to run some cron task outside the scope of the app, then you can use a script like below and put it in the crontab of your server.
# this is the app's domain name
# detect the container id of the app
container_id=$(docker ps -q -f label=fqdn=$app -f label=isSubcontainer=false)
echo "App container id is : $container_id"
# we can now run arbitrary commands in the container. below we run a command as the www-data user.
docker exec $container_id sudo -u www-data ls -l