The problem
The pattern is unmistakable once you can see it: CPU or IO-wait jumps at the same minute every day or every hour. That is not traffic — that is a schedule. But without load history you never notice the regularity, and without a crontab overview you cannot tell which of a hundred jobs across forty accounts fires at that minute.
The solution
VpsMonitor.Pro gives you both halves of the answer. The history charts (CPU, IO-wait, memory, network — stored locally) reveal the recurrence: scroll back a day, a week, and the spike sits at the same timestamp like a metronome. The Cron view then shows every job on the server with its schedule — finding the ones that run at 03:17 is a glance, not an investigation.
For confirmation, the “who is loading the server?” snapshot taken during the spike lists the actual running processes — and its special processes section already separates known maintenance work (backups, certificate renewals, scans) from the suspicious rest. The AI analysis button will even judge whether a long-running job is normal maintenance or worth fixing.
The usual outcome: two heavy jobs land on the same minute. Spreading them by twenty minutes makes the nightly spike vanish without touching any code.
Frequently asked questions
How do I correlate a past spike with a cron job if I wasn’t watching?
The metric history is stored locally, so you scroll the chart back to the spike, note the exact time, and match it against the schedules in the Cron view.
Are panel maintenance jobs (backups, certbot) a problem?
Usually not — they are supposed to run. They become a problem when several heavy jobs overlap; staggering their minutes is the standard fix.
Can WordPress cause cron-like load without a crontab entry?
Yes — wp-cron fires on page visits, which looks random. A real recurring spike at a fixed minute almost always traces to an actual crontab or system timer.
Get a license · Download free — 7-day trial