Featured

Diagnosing an unreachable Linux VPS

Published on 21/08/2026 Updated on 06/10/2026 93 views
Support VPS Linux Diagnostic

"My server is down" covers a dozen very different situations. The method below separates them in a few minutes and saves you waiting for an answer when the fix was a click away.

1. How do I check the state of my VPS in the client area?

Open My services then your VPS. The page shows the state of the machine.

  • Stopped: click Start. A stop may follow a mistaken shutdown, a crashed kernel or an earlier action.
  • Installing: nothing to do, wait for it to finish.
  • Suspended or expired: check your invoices in the client area. An unpaid service is suspended.

2. Where do I see the latest actions performed on my VPS?

The History tab lists actions performed on the VPS, who performed them — System, User or Administrator — and when. A reinstallation, a password change or a forgotten shutdown appear there in black and white. The explanation is often right here.

3. What do the graphs of my VPS show?

The Graphs tab shows CPU, memory, network and disk I/O. Three useful readings:

  • everything flat at zero since a precise time: the machine is stopped or frozen;
  • CPU pinned at the ceiling continuously: a process has run away, or someone other than you is using the machine;
  • unusual outbound traffic: seriously consider a compromise.

4. How do I see what is happening on the machine with the console?

This is the decisive step. The console shows the machine's screen without using the network.

  • You see the login prompt: the system is running, the problem is networking or SSH. Go to step 5.
  • You see errors during boot: note the last line before it stops, that is the one that matters.
  • The screen is black and unresponsive: reboot from the service page, then watch the boot in the console.

5. How do I check networking and SSH from the console?

A handful of commands tell the whole story: the address and the default route, a ping to a public IP then to a domain name, the state of the SSH service, and whether fail2ban has banned your address.

Log in through the console as root:

ip -4 addr          # is the address actually there?
ip route            # does a default route exist?
ping -c3 9.9.9.9    # does the IP layer work?
ping -c3 debian.org # does DNS resolve?

If 9.9.9.9 answers but a domain name does not, fix DNS resolution. If nothing answers, compare your configuration with what the Network tab of the client area shows.

Then SSH and the firewall:

systemctl status ssh          # or sshd
ss -tulpn | grep :22
ufw status                    # or firewall-cmd --list-all
fail2ban-client status sshd   # is your own IP banned?

An address banned by fail2ban after several wrong passwords is a very common cause of an "unreachable" server that is in perfect health. Unban it with fail2ban-client set sshd unbanip YOUR_IP.

6. How do I know whether the disk of my VPS is full?

With df -h for space and df -i for inodes: a saturated disk stops services from starting and logs from being written.

df -h
df -i
journalctl --disk-usage

A disk that is 100 % full — or out of inodes, which df -h does not show — stops services from starting and logs from being written. Free some space, then restart the affected services.

7. How do I spot a failed service on my VPS?

With systemctl list-units --failed, then the log of the service concerned: the cause is almost always written there in plain words.

systemctl list-units --failed
journalctl -p err -b --no-pager | tail -50
systemctl status SERVICE_NAME

A service that failed after an update is almost always explained in plain words in its own log.

What should I include in my support ticket?

If you open a ticket with the Service Technique, these items save several round trips:

  • the identifier of the service concerned;
  • the exact time the problem started, with the time zone;
  • what changed just before: an update, a firewall, network or SSH change;
  • the output of the commands above, pasted as text;
  • the exact error message, not a summary;
  • what the console displays.

Never send a password, a private key or a token: support does not need them, and tickets are archived.

Was this article helpful?