Heya,

Hi Alexander,

What you’re describing almost always turns out to be something happening inside the droplet rather than an infrastructure issue. If a reboot immediately restores normal operation, that’s a strong sign the problem is a runaway process, memory exhaustion, or something at the application level.

On WordPress droplets, the usual causes are a plugin going wild (backup, security, search, etc.), overlapping wp-cron jobs, aggressive bot traffic hitting login or XML-RPC, or MySQL consuming too much memory/CPU. When memory gets exhausted, the kernel can start killing processes (OOM), and the system may appear frozen.

The most helpful thing you can do is capture data before rebooting next time. If SSH is still responsive, run top or htop and see what process is at 100%. Also check for out-of-memory events with:

dmesg -T | grep -i oom

or

grep -i kill /var/log/messages

If you see “Killed process …” messages, that confirms memory exhaustion.

It’s also worth checking logs around the time of the spike:

/var/log/syslog

/var/log/nginx/error.log or /var/log/apache2/error.log

MySQL logs if enabled

If you’re using default WordPress cron, consider disabling it in wp-config.php and moving it to a real system cron job. Overlapping cron runs are a common source of CPU spikes.

From the platform side, actual host node issues are rare and usually show up as disk I/O errors or kernel messages in dmesg/journalctl. If you’re not seeing hardware or filesystem errors, it’s very unlikely to be the underlying infrastructure.

If you can share the droplet size, whether swap is enabled, and what process shows high CPU during a spike, that would make it much easier to narrow this down further.

Hope that this helps!