Server Resource Triage Checklist for CPU RAM Disk and Network
Many website issues are resource issues in disguise. A slow WordPress site, 504 error, failed backup, database crash or Docker container restart may be caused by CPU, RAM, disk or network pressure.
Core principle
Before editing application settings, check the machine. If the server is out of memory, full disk or under CPU pressure, application-level fixes will not solve the root problem.
Checklist
- Check CPU load.
- Check memory usage.
- Check swap usage if enabled.
- Check disk space.
- Check disk inode usage if files are too many.
- Check top processes.
- Check whether MySQL, PHP-FPM or Docker is consuming resources.
- Check access logs for bot spikes.
- Check whether backup, import or cron jobs are running.
- Document the bottleneck before taking action.
How to think
CPU high means something is working too hard. RAM full means processes may be killed or slowed. Disk full means services may fail to write. Network issues may show as timeouts or external API failures.
When to Use This Checklist
Use this checklist when a VPS website, WordPress site, Docker app or automation service becomes slow, unstable or returns timeout errors.
Required Tools
SSH access, Linux terminal, top or htop, Nginx logs, process list, VPS monitoring dashboard
Before You Start
Do not restart services blindly. First identify whether CPU, RAM, disk or network is the real bottleneck.
Structured Checklist Steps
- Check CPU load.
- Check memory.
- Check swap.
- Check disk usage.
- Check inode usage.
- Find top processes.
- Check MySQL and PHP-FPM usage.
- Check Docker usage if relevant.
- Check bot traffic.
- Record the bottleneck.
Verification Steps
- Resource bottleneck is identified.
- Top process is known.
- Disk has safe free space.
- RAM is not exhausted.
- Server load drops after mitigation.
Rollback Plan
If a cleanup or restart causes new issues, revert the last change and use provider snapshots or service-specific backups if available.
Common Mistakes
- Restarting everything before checking resources.
- Ignoring disk inodes.
- Assuming traffic is real users.
- Not checking cron jobs.
- Deleting large files without knowing what they are.
Related Commands
top
free -h
df -h
df -i
ps aux --sort=-%mem | head
ps aux --sort=-%cpu | head
sudo tail -n 100 /var/log/nginx/access.log