5 Signs Your Server Needs Immediate Attention Before It Crashes

Servers do not simply fail without warning. In almost every case, there are clear signals in the days or hours before a serious incident. The problem is that most business owners and even many website managers do not know what to look for. Here are the 5 most reliable warning signs — and what to do about each one.

Sign 1: RAM Usage Consistently Above 85%

When a server's RAM is consistently near capacity, the operating system starts using swap space (disk-based virtual memory) instead. Disk is 100x slower than RAM. Once a server is swapping heavily, response times balloon, sites slow dramatically, and the server becomes vulnerable to being overloaded by even modest traffic spikes.

Check it: Run free -h on your server. If "used" under Mem is consistently above 80-85% of total, you have a problem.

Fix it: Identify what is consuming RAM with ps aux --sort=-%mem | head -20. Common culprits: MySQL with an oversized buffer_pool_size, PHP-FPM with too many child processes, or memory leaks in application code.

Sign 2: Disk Usage Above 80%

A full disk causes catastrophic failures — MySQL stops writing, PHP sessions fail, logs cannot be written, and email bounces. Disk fills up faster than most people expect: log files accumulate, database backups stack up, and email attachments add up silently.

Check it: Run df -h. Any partition above 80% needs attention immediately. Above 90% is an emergency.

Fix it: Run du -sh /var/log/* | sort -hr | head -20 to find large log files. Check for old backup files in /home directories. Verify your backup rotation is working correctly — old backups not being deleted is a very common cause of full disks.

Sign 3: CPU Spikes to 100% Regularly

Occasional CPU spikes are normal. Sustained 100% CPU usage or spikes that happen multiple times per day indicate a problem — either a performance issue in your application code, a bot/scraper hammering your site, or a compromised server running malicious processes.

Check it: Run top or htop. Look at the processes consuming the most CPU. Is it PHP-FPM (your site), MySQL, or something unfamiliar?

Fix it: Unfamiliar processes at high CPU are a red flag for compromise. PHP consuming 100% CPU constantly often indicates a malware infection or an inefficient query. MySQL at 100% points to missing indexes or poorly optimised queries.

Sign 4: Slow Response Times That Were Not There Before

If your site suddenly takes 3-5 seconds to load when it used to load in under a second, and nothing changed in your code or content, the problem is at the server level. This is often caused by: a recently installed plugin making slow external API calls, a database that has grown significantly in size without optimisation, or a gradual memory leak building up.

Check it: Run mysqltuner (install with apt install mysqltuner) to get a diagnosis of MySQL performance issues. Check PHP slow log if enabled.

Sign 5: Increasing Number of 502/503 Errors

502 Bad Gateway and 503 Service Unavailable errors mean the web server (Nginx) cannot get a response from PHP-FPM — the processor running your PHP code. This happens when PHP-FPM runs out of worker processes. Each website visit spawns a PHP-FPM process; if all processes are busy, new requests queue up, then time out, producing 502/503 errors for visitors.

Check it: Look at your Nginx error logs: tail -100 /var/log/nginx/error.log. If you see "connect() to unix:/run/php/php8.x-fpm.sock failed" errors, PHP-FPM is exhausted.

Fix it: Increase pm.max_children in your PHP-FPM pool configuration. The correct value depends on your available RAM and average PHP memory per request. As a starting point: (available RAM in MB) / 40 = max_children value.