When an application slows down or stops responding, measure first and increase VPS resources only afterwards. CPU load, memory usage, disk capacity and service logs can point to different causes.
This guide uses safe, read-only commands to gather troubleshooting evidence, then helps distinguish application issues from a genuine need for a larger plan.
1. Record the symptom and timestamp
- Is just one page slow, or are SSH and other services affected too?
- When did it start, and did an installation, update or traffic increase precede it?
- Is the issue intermittent or persistent? Is there a corresponding HTTP 5xx response or application error?
2. Check system status
| Jel | A useful follow-up question |
|---|---|
| High CPU load | Which process is using it, and for how long? |
| Low available memory | Is memory insufficient, or is swap used frequently? |
| Full filesystem | Which mount point is full? |
| Inodes exhausted | Have many small files or logs been created? |
uptime
free -h
df -h
df -i
ps aux --sort=-%cpu | head -n 12
ps aux --sort=-%mem | head -n 123. Narrow down the issue using service logs
If you know the service's systemd unit name, such as nginx.service, use these commands to inspect its status and recent errors.
systemctl status nginx.service --no-pager
sudo journalctl -u nginx.service --since '1 hour ago' --no-pager
sudo journalctl -p err --since '1 hour ago' --no-pager4. Do not automatically choose a larger plan
- If a process uses unusually high resources, check its recent changes and error logs.
- If the disk is filling up, identify which data is growing; do not delete backups or logs at random.
- If capacity limits persist under documented load, estimate the additional CPU, RAM or storage required.
- If you suspect an outage or data loss, request help with measurements and timestamps.
