Server unreachable? A step-by-step diagnosis

When your website, SSH and Remote Desktop all stop answering at once, the cause is usually one of a few things: a network problem between you and the server, a suspended service, a firewall rule, or a server that has crashed or run out of resources. This guide works from the outside in. Replace 203.0.113.10 with your server's address.

Step 1: Check the status pages

• Support › Network Status in the client area lists known incidents and planned maintenance. If one matches, follow its updates.
• Services › My Services shows the status of your service. Suspended usually means an overdue invoice: pay it under Billing › My Invoices and the service is reactivated. Cancelled or Terminated means the service has ended.

Step 2: Is it everyone or just you?

Test from your computer, then from a second network (a mobile hotspot or a friend's connection):

ping -c 5 203.0.113.10
mtr -rwc 50 203.0.113.10

Test-Connection 203.0.113.10 -Count 5
tracert 203.0.113.10
pathping 203.0.113.10

• Works from the second network: the problem is in your own network or internet provider, or your IP address is blocked by the server's firewall or by Fail2ban.
• Fails everywhere, and the trace stops near the end: the server itself or its firewall does not answer. Continue with Step 3.
• Fails everywhere, and the trace stops early: a routing problem along the path. Save the output for a ticket.

Note that some servers do not answer ping by design. Test the actual service ports too: nc -vz 203.0.113.10 22 or Test-NetConnection 203.0.113.10 -Port 443.

Step 3: Look at the server through the console

If your service page shows a Web console (in the Actions menu or the Manage card), open it. It shows the server's screen even when the network is down.

• A login prompt: the server runs. Log in and continue with Step 4.
• Error messages or a frozen screen: the server crashed or hangs. If your service page offers a reboot action, use it, then go to Step 5.
• Boot errors, for example about the file system: note the message and open a ticket.

On dedicated servers, use IPMI where your plan includes it. Without any console, open a ticket.

Step 4: Find the cause inside the server

Logged in through the console, check the basics:

ip -brief address
ip route
systemctl --failed
df -h
free -h

• No IP address or no default route: the network configuration is broken, often after an edit to netplan or /etc/network/interfaces. Revert the change and apply it again.
• Failed services: read their log, for example sudo journalctl -u nginx -n 50.
• A full disk (Use% at 100): services fail when they cannot write. See disk full.
• No free memory: see high CPU or memory usage.

Then check the firewall, which is the most common cause after a change:

sudo ufw status verbose
sudo nft list ruleset

If you locked yourself out, follow locked out after a firewall change.

Step 5: Read the logs of the previous boot

After a crash and reboot, the reason is often in the log of the boot before. If the journal is persistent (it is by default on current Ubuntu and Debian releases), run:

journalctl --list-boots
sudo journalctl -b -1 -p warning
sudo journalctl -k -b -1 | grep -i -E 'out of memory|oom|panic|error'

Look for out-of-memory kills, disk errors and kernel messages just before the end.

Windows servers

Through the web console, sign in and check Event Viewer › Windows Logs › System for errors around the time the server stopped responding. Make sure the network adapter has its IP address (Get-NetIPAddress) and that the Remote Desktop firewall rules are enabled. See Remote Desktop connection problems.

Suspect an attack?

Sudden unreachability together with heavy traffic graphs or a flood of connections can mean a DDoS attack. Do not keep rebooting. Open a ticket with the affected IP addresses, the start time and any logs; see DDoS protection basics.

When to open a ticket

Open a ticket with the server selected under Related Service when the server fails from every network and the console shows nothing useful, when the trace stops inside our network, or when you see hardware or disk errors. Include the time with time zone, the mtr or pathping output, what the console shows and what changed recently.

Next steps

• Specific errors: SSH connection problems and Remote Desktop connection problems.
• Prevent the next outage: automatic updates and backup strategy.