The problem
On a shared server, every account can have its own crontab. They live scattered in /var/spool/cron/, nobody reviews them, and over the years they accumulate: backup scripts pointing at dead paths, WordPress pseudo-crons hammering sites every minute, customer “temporary” jobs from 2019, and occasionally something malicious persisting after a compromise. There is no built-in overview.
The solution
VpsMonitor.Pro’s Cron view lists every user’s crontab in one table: account, schedule, and the exact command, refreshed live over SSH. Sorting and scanning the whole server takes seconds — including the system cron directories where panel and maintenance jobs live.
Cleaning is built in and done correctly: deleting an entry rewrites the user’s crontab through crontab -u, so the cron daemon reloads it properly — never by editing spool files behind its back. Account names are validated before any command runs, and the deletion asks for confirmation with the exact entry shown.
Reviewing this list is also a fast security win: a crontab line that downloads and pipes something to shell is one of the most common persistence tricks after a site compromise.
Frequently asked questions
Can I see system cron jobs too, not just user crontabs?
Yes — panel and maintenance jobs in the system cron directories are listed alongside the per-user crontabs, so the picture is complete.
Why must crontabs be edited via crontab -u instead of the spool file?
The cron daemon caches crontabs and watches them through the proper interface. Direct spool edits can be ignored or overwritten — crontab -u guarantees the change takes effect.
What suspicious patterns should I look for in a crontab?
Jobs fetching remote URLs and piping them to a shell, entries running every minute for no reason, and commands hidden in long base64 strings — all classic persistence techniques.
Get a license · Download free — 7-day trial