The symptom
Reports stop arriving, old records are no longer cleaned up, a sync falls behind. There is no exception and no failed job, because nothing ran.
Check it yourself
Look for the cron line, and make sure the path in it is the site's current directory:
grep -rs "schedule:run" /etc/cron.d /var/spool/cron/crontabs
sudo -u <site user> crontab -lThen see what the application expects to run:
php artisan schedule:listTasks listed and no working cron line for this directory: the scheduler is not running. A line whose cd or artisan path no longer exists fails every minute into /dev/null, silently.
How it happens
On a server we run, a site's directory was renamed. Its only scheduler cron line still pointed at the old path, and the scheduler stayed stopped for five weeks before anyone noticed. A worker started from cron on the same path stopped with it.
The fix
Add one cron line, as the site's user, with the PHP version the site runs and the real path:
* * * * * php8.4 /home/shop/shop.example.com/artisan schedule:run >> /dev/null 2>&1- One scheduler per application: two lines run every task twice. Remove the dead line first, then add the new one.
- Before you start a scheduler that has been stopped for long, read
php artisan schedule:list: everything on it starts running again within the minute. - Instead of cron, a supervisor program running
php artisan schedule:workdoes the same job.
How Hostio finds it
The scan counts the scheduled tasks your code defines (routes/console.php, bootstrap/app.php, app/Console/Kernel.php) and looks for a live schedule:run cron line or schedule:work program for the site's directory. Tasks with no scheduler raise scheduler_missing, a danger insight.
On Pro, the site's Cron jobs tab has a Laravel scheduler preset that writes exactly this line, after a preview; Hostio refuses a second scheduler for the same site. If a site has no scheduler on purpose, mute the insight with a reason.