My VPS is slow or down: what to check

Part 5 of the Running your VPS series.

Your site will not load, SSH hangs, or everything is suddenly slow. This guide gives you a calm, step-by-step way to find out why. It starts from the outside, working out whether the server is reachable at all, and moves inwards to memory, disk, CPU and the services themselves. At the end it shows what to send support if the problem is on their side.

It assumes a Linux VPS running Ubuntu or Debian. Most checks work the same on other distributions. Work through the steps in order. Most problems show up in the first four.

What is in this guide

• First: do not make it worse
• 1. Is it you, or the server?
• 2. Can you reach the server at all?
• 3. Use the control panel console
• 4. Check memory
• 5. Check disk space
• 6. Check CPU
• 7. Check the service itself
• 8. Check the network and bandwidth
• 9. Check your email for notices
• When to contact support
• Quick reference
• Preventing the next one
• Limits
• When to step up
• More in the series

First: do not make it worse

• Do not reinstall straight away. A reinstall wipes the server. Only do it if you have a backup and nothing else works.
• Write down what changed. Did you update packages, edit a config file, change the firewall or install something just before the problem? That is often the answer.
• Change one thing at a time. Then check whether it helped.
• A reboot is fine as a last resort, but read the logs first if you can, because a reboot can hide the cause.

1. Is it you, or the server?

Before blaming the server, rule out your own connection and DNS.

• Try the site on your phone using mobile data instead of Wi-Fi.
• Check DNS still points to your server: dig example.com +short should show your server's IP address. If it does not, see domains and DNS explained.
• Check your domain has not expired. An expired domain looks exactly like a dead server.
• If you have a monitor on another server, check what it saw and when.

2. Can you reach the server at all?

From your own computer:

ping -c 5 SERVER_IP
ssh alex@SERVER_IP

On Windows, use ping -n 5 SERVER_IP. Replace SERVER_IP with your server's address.

Ping	SSH	What it suggests
Works	Works	The server is up. The problem is a service, memory, disk or CPU. Go to step 4
Works	Hangs or refused	SSH stopped, the firewall blocks it, or the server is overloaded. Go to step 3
Fails	Fails	The server is off, stuck, suspended or has a network problem. Go to step 3

Some servers block ping on purpose, so a failed ping alone is not proof the server is down.

3. Use the control panel console

Log in to the VPS control panel from your welcome email. It usually shows whether the server is running, and offers a console, which is like plugging a screen and keyboard into the server. It works even when SSH and the network do not.

• If the server is stopped, start it, then check the logs to find out why it stopped.
• If the console shows a login prompt, log in and carry on from step 4.
• If the console shows errors about the disk or a failed boot, note them down for support.
• If you locked yourself out with the firewall, fix it from the console, for example with sudo ufw allow OpenSSH.
• If you cannot log in to the control panel or it shows the service as suspended, go to step 9.

4. Check memory

Running out of memory is the most common cause of a slow or broken small server.

free -h
sudo dmesg -T | grep -i -E "out of memory|killed process"

The first command shows memory and swap. The second shows whether the system has stopped programs to free memory.

• Swap heavily used and little memory free: the server is short of memory. That makes everything slow.
• "Killed process" lines: the system stopped a program, often your database or web server, to save itself. That program needs restarting.

To see what is using memory, run top and press Shift+M to sort by memory. Press q to quit. Restart or stop whatever is using too much. If it happens again and again, the job needs a bigger plan or a lighter setup. Swap helps briefly, but it is a safety net, not extra RAM.

5. Check disk space

A full disk stops databases, logs and updates, and can make a site fail in strange ways.

df -h
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 20

The first command shows how full each disk is. The second lists the biggest folders. Common culprits:

• Logs. Check /var/log. Clear old system logs with sudo journalctl --vacuum-time=7d.
• Docker. Old images and containers add up. docker system df shows how much space they use.
• Package caches. sudo apt clean removes downloaded package files.
• Backups or dumps left on the server itself.

Delete carefully. If you are not sure what a file is, move it or look it up before removing it.

6. Check CPU

uptime
top

uptime shows the load average: three numbers for the last 1, 5 and 15 minutes. As a rough guide, a load well above your number of CPU cores, which nproc shows, means the server has more work than it can keep up with.

In top, look at the top line for:

• us: your programs. High means something is busy. The process list shows which.
• wa: waiting for the disk. High often means the disk is the bottleneck.
• st: steal time, waiting for the shared physical CPU. Often high means the host is busy, and is worth mentioning to support.

A program using lots of CPU you do not recognise can be a sign the server has been compromised, for example by a cryptocurrency miner. If you suspect that, see Limits.

7. Check the service itself

If the server is healthy but the site is not, look at the service. For nginx:

sudo systemctl status nginx
sudo journalctl -u nginx --since "1 hour ago"
sudo tail -n 50 /var/log/nginx/error.log

Change nginx to the service you are checking, such as mariadb, PHP-FPM (its service name includes the PHP version number) or your app's service name. systemctl list-units --type=service lists them. For Docker apps, use docker ps -a and docker logs CONTAINER_NAME.

If the service has stopped, start it with sudo systemctl start nginx and read the error that comes back. A config mistake is a common cause after an edit. For nginx, sudo nginx -t checks the config and points to the line.

8. Check the network and bandwidth

• Slow from one place only. Test from another network or another server. A route problem between you and the data centre can make one location slow while others are fine. mtr SERVER_IP, run from your computer, shows where along the route the delay starts.
• Bandwidth used up. Check the control panel's bandwidth figure for the month. Some plans slow down or suspend traffic when the allowance runs out. Unmetered does not mean unlimited.
• Sudden traffic. A spike in your access log can be popular content, a bot crawling your site or an attack. Look at sudo tail -f /var/log/nginx/access.log for repeated requests from the same addresses.

9. Check your email for notices

Search your inbox, including spam, for messages from RackNerd. Look for:

• An unpaid invoice. Servers are usually suspended when payment is overdue.
• An abuse or fair-use notice. Heavy CPU use, a complaint about spam or a security problem can lead to a server being limited or suspended. Read the notice and reply as it asks.
• A maintenance or outage notice. Planned work or a known problem in the data centre.

When to contact support

Contact RackNerd support when the problem is outside your server: the server will not start, the console shows hardware or disk errors, the network is down for everyone, steal time stays high, or you have a notice you need to discuss. A RackNerd VPS is unmanaged, so support can help with the server and network, but usually not with your apps.

A good ticket gets a faster answer. Include:

• The server's IP address and hostname.
• What you see, when it started, and whether it is constant or comes and goes.
• What you have checked, such as "ping fails, console shows a login prompt, memory and disk are fine".
• Output from mtr or ping, if it is a network problem.
• Any error messages from the console, copied exactly.

Quick reference

Symptom	Likely cause	Fix
Site and SSH both dead	Server stopped, suspended or network down	Check the control panel, your email and the console
SSH refused after a change	Firewall or SSH config mistake	Fix it from the control panel console
Everything slow, swap full	Out of memory	Find the program with top, restart it, then reduce load or step up
Database keeps stopping	Killed for using too much memory	Check dmesg for "killed process". Tune it or move up a size
Site errors, database cannot write	Disk full	Find big folders with du and clear logs and caches
502 Bad Gateway	The app behind nginx is not running	Check the app's service or container logs
High CPU from an unknown program	Runaway job, or a compromised server	Investigate. If compromised, see Limits
Slow only from your location	Network route problem	Run mtr and send the result to support

Preventing the next one

• Monitor from outside. A small check on another server tells you when your site goes down. See what you can do with a 512 MB VPS.
• Keep backups off the server. Then a reinstall is an inconvenience, not a disaster. See using a storage VPS for backups.
• Leave headroom. Aim to use well under the plan's memory and disk, not right up to the limit.
• Rotate logs. Make sure old logs are cleaned up automatically.
• Keep notes. Write down what you install and change. Future you will need them.
• Keep it secure. See securing your VPS.

Limits

• This guide covers common causes, not every possible fault.
• If you suspect a hack, do not just delete the strange program. An attacker may have left other ways back in. The safest path is usually to take the server offline, copy off your data, check it carefully, and rebuild on a fresh install with new passwords and keys. Tell support if your server may have attacked others.
• Restarting is not fixing. If a service keeps failing, find the cause, or it will happen again at a worse time.
• Fair-use limits may be the cause. A server that runs at full CPU for long periods may be limited by the provider. That is a sign the job needs a bigger plan or a dedicated server.

When to step up

If you keep running out of memory, move up a size. If the CPU is busy all day, look at more cores or a dedicated server. If you move, moving to a new VPS walks you through it.

To compare what is available now, start with the cheapest RackNerd VPS guide and check the sales page.

More in the series

This is part 5 of 5. Previous: Moving to a new VPS. Next: back to the start with How to read VPS specs. See the whole series.