Diagnosing a slow or unresponsive server: a step-by-step flow

Before you start digging: check for a known incident: If more than one service or server looks affected, check the Network Operations Center status page first. If there's an active incident or scheduled maintenance, that's your answer, no need to work through the steps below.

"The server is slow" can mean a dozen different things. Guessing wastes time, and it means you contact support without the information that would let them help you faster. This is the order that finds the cause fastest, because each step is quick to check and rules out an entire category before you move to the next.

1. Check CPU first

Run top or htop. Look at load average relative to your core count, not just the raw number: a load of 4 on a 2-core VPS is saturated, the same load on a 16-core server is barely noticeable. Look for one runaway process versus load spread evenly across many.

If CPU is pegged: identify the process, decide if it's expected (a batch job, a backup) or not (something that shouldn't be running). If your VPS plan is genuinely undersized for the workload, see Signs you've outgrown your VPS.

2. Check memory next

Run free -h. A high "used" number on its own isn't a problem, Linux uses spare RAM for disk cache and reclaims it automatically. What matters is swap usage: if swap is actively being used and growing, the server is genuinely out of memory, and that alone can make everything feel slow, since swap is far slower than RAM.

If you're swapping heavily, a resize (more RAM) is usually the direct fix, see Managing a Flexible VPS for how to adjust resources.

3. Check disk I/O

Run iostat -x 2 (from the sysstat package) and watch %util and await. A disk pinned near 100% utilisation, or await times climbing into the tens of milliseconds, points at storage as the bottleneck, not CPU or memory.

Rule out a failing drive before assuming it's just load: see How to recognise a bad drive in Linux. For a deeper look at what "slow" actually means for your storage tier, see Storage benchmarking: IOPS, throughput and latency.

4. Check the network

If CPU, memory, and disk all look fine but the server still feels slow to reach, the problem may not be on the server at all. Run a traceroute from where you're connecting from, and check for packet loss or a hop with a sudden latency jump. See Traceroutes & MTRs for how to read the output, and How to do a speedtest to rule out a bandwidth ceiling.

If the server itself is unreachable rather than just slow, check Network Topology in Portal to confirm the VPS or firewall it sits behind is actually in the state you expect.

5. Read the logs

If the first four steps didn't explain it, the answer is usually in a log you haven't looked at yet: the application's own log, dmesg for kernel-level events (like a process being OOM-killed, which explains a memory issue after the fact), or your web server's access log for a traffic spike. See Reading and centralising server logs for where to look and how to pull logs from more than one server into one place.

Still stuck? Open a ticket with what you've ruled out

A ticket that says "server is slow" takes longer to resolve than one that says "CPU and memory are normal, disk await is climbing to 40ms on the data volume, here's the iostat output." Attach what you found at each step, see Creating a support ticket for what else to include and how to pick a priority.

If you suspect compromise, not just slowness: Unexpected CPU spikes, unfamiliar processes, or outbound traffic you can't account for can also mean the server has been compromised rather than simply overloaded. If anything here looks suspicious rather than just slow, stop and read What to do if your server is compromised before continuing.