A WooCommerce shop with stuck actions
Thousands of scheduled actions stay pending and emails go out late. LayerAssist finds the failing action, gets the queue moving and sets up a real cron.
Know your scheduled jobs actually ran.
Backups, emails, imports, scheduled posts: much of your site’s work happens in the background, on a schedule. LayerAssist checks that those jobs run, finds out why one didn’t and gets it going again.
At a glance
- In chatIn chat, it lists your cron jobs, reads their logs, checks WordPress’s scheduler and background workers, and fixes the job that doesn’t run.
- AutomationAs your own automation, it can check every morning that last night’s jobs ran, for example that a fresh backup exists, and tell you when one didn’t.
- Built-in monitorIf your queue worker runs as a service, the built-in service monitor alerts you the moment it stops.
- Not available yetA built-in heartbeat monitor for cron jobs isn’t available yet.
Background jobs fail without a sound
Cron jobs and queues do their work while nobody is watching: nightly backups, invoice emails, product imports, cache cleanups, scheduled posts. When one stops there’s no error page; the work simply doesn’t happen.
You find out later, the hard way: the backup you need is three months old, customers never got their invoices, the morning post never went live.
Signs a scheduled job isn’t running
- Backups stopped appearing, or are older than they should be
- Scheduled posts show “Missed schedule”
- Daily emails or exports have stopped
- A queue keeps growing and jobs stay “pending”
Why cron jobs and queues stop
WordPress’s scheduler only runs on visits
WP-Cron runs when someone visits the site. On a quiet site, or behind a cache, scheduled tasks run late or not at all.
A broken path or environment
A job that works by hand fails on schedule because of a different PHP version, a missing path or a moved script.
The worker process stopped
Queue workers must run all the time. After a crash, a deployment or a reboot, nothing starts them again.
Jobs that crash or pile up
One failing job, a lock that never clears or a job that runs longer than its interval blocks everything behind it.
How LayerAssist keeps your background jobs running
It checks the schedule, the logs and the result: what the job should have produced.
Lists what’s scheduled
It reads the server’s crontab, your hosting panel’s cron jobs and WordPress’s scheduled events, and explains each one.
Checks the job really ran
It looks for evidence: the log entry, the fresh backup file, the sent email, the emptied queue.
Finds why one failed
It runs the job’s command the way cron does, reads the error, then fixes the path, the PHP version or the permissions.
Sets it up properly
It can replace WP-Cron with a real server cron, set up workers that restart by themselves and add logging, so failures leave a trace.
Example: backups that quietly stopped
What it checks
- Crontab: backup job scheduled at 02:00 every night
- Latest backup file: 74 days old
- Cron log: the job fails with “mysqldump: command not found”
- Cause: a server update moved the tool, and the job still uses the old path
What it changes
Corrected the path in the backup script, ran it once and set it to email you if it fails
What you get
- Proof that jobs ran, not just that they’re scheduled
- Failures found the morning after, not months later
- WordPress scheduled tasks that run on time
- Queue workers that come back after a crash
Real situations
A Laravel app with a queue
After a deployment, the queue worker never restarted. LayerAssist puts it under a supervisor so it restarts by itself, and suggests a service monitor.
A news site with scheduled posts
Posts scheduled for 6 am appear at noon: behind the cache, WP-Cron only ran when the cache expired. A server cron fixes it.
How to check your cron jobs with LayerAssist
Connect the server or hosting
SSH gives the full picture; a hosting panel shows its cron jobs too.
Ask for a check
In chat: “Are our scheduled jobs running?” or “Why did last night’s import fail?”
Let it fix the job
It finds the cause, fixes it and runs the job once to prove it works.
Turn it into a morning check
Ask for a daily check as your own automation, and add the service monitor for queue workers that run as a service.
Questions about cron job monitoring
Cron is the server’s own scheduler and runs on time. WP-Cron is WordPress’s built-in scheduler and only runs when someone visits the site. For reliable timing, LayerAssist can trigger WP-Cron from a real server cron.
Yes, with SSH access. It checks the worker processes, the failed jobs and the queue length, and can run workers under Supervisor or systemd so they restart by themselves.
With a scheduled check as your own automation: each morning, for example, it looks for evidence that your jobs ran and tells you when one is missing. A built-in heartbeat monitor isn’t available yet.
Reading your own user’s cron jobs and logs works with a normal login. Changing system services or other users’ jobs needs sudo, which is included from the Plus plan.
Related guides
- Built-in monitorServer servicesAlerts you when a service like your database stops.
- AutomationWordPress updatesChecks for updates daily, backs up, updates and tests.
- AutomationApplication errorsReads your error logs on a schedule and explains what matters.
All monitoring guidesSee what each plan includesHow LayerAssist works
From $9 a month · 14 days to change your mind
Next time something breaks, you’ll know who to ask.
Add your website and ask your first question today. Not for you? Cancel within 14 days to get your first payment back, minus only the AI work you used.
Free for 7 days · No credit card needed · No technical knowledge needed.