A server that is not responding can be alarming, but in most cases the issue can be identified and resolved quickly. This guide takes you through a systematic troubleshooting process — from basic connectivity checks to diagnosing common root causes — so you can get your server back online as fast as possible.

Step 1 — Check If the Problem Is on Your End

Before investigating your server, rule out issues with your own internet connection and network:

Is It Just You?

• Try accessing your server from a different network. Use your mobile phone's cellular data (not Wi-Fi) to test connectivity. If the server responds from your phone but not from your computer, the issue is with your local network or ISP.
• Check other websites. If you cannot access any websites, your internet connection is likely down.
• Ask a colleague or friend to try accessing your server's IP address or website from their network.
• Use an online tool. Websites like "Down For Everyone Or Just Me" or online ping tools can test reachability from multiple locations worldwide.

Check Your Local Network

• Restart your router or modem.
• Try a different device on the same network.
• Temporarily disable your VPN if you are using one — some VPNs block certain ports or routes.

Step 2 — Check Server Status in Your Dashboard

Log in to your Data Mammoth dashboard and navigate to Services > [Your Server].

Check the following:

• Server status. Is it showing as Active, Stopped, or Suspended?

• Resource usage graphs. Check CPU, RAM, and disk usage. Spikes or 100% utilization can cause the server to become unresponsive.
• Recent events. Look for any recent events such as reboots, OS reinstalls, or maintenance notifications.

Restart From the Dashboard

If the server shows as Active but is not responding, try a restart:

If a normal restart does not work, try a hard reboot (force restart) if the option is available. This is equivalent to pulling the power cord and plugging it back in — it forces the server to stop and restart immediately.

Step 3 — Ping Your Server

From your local computer, test basic network connectivity using the ping command. Open a terminal (macOS/Linux) or PowerShell (Windows) and run:

ping 203.0.113.10

Replace 203.0.113.10 with your server's actual IP address.

Interpreting Results

• Replies received (e.g., 64 bytes from 203.0.113.10: time=25ms) — The server is reachable at the network level. The issue is likely with a specific service (web server, SSH daemon) rather than the server itself.
• Request timed out or 100% packet loss — The server is not reachable. This could indicate the server is down, a network issue in the data center, or a firewall blocking ICMP (ping) packets.
• Destination host unreachable — A routing issue exists between your network and the server. This is typically an infrastructure-level problem.

Step 4 — Use the Web Console

If you cannot connect via SSH or your website, use the web-based console available in your Data Mammoth dashboard:

The web console bypasses network issues, firewalls, and SSH configuration problems. If the server is running, you can log in through the console and investigate the issue from inside the server.

What to Check via Console

Once logged in through the web console:

# Check if the server is overloaded
top
Check available memory
free -h
Check disk space
df -h
Check network interfaces
ip addr
Check if SSH is running
systemctl status sshd
Check if the web server is running
systemctl status nginx    # or apache2, httpd

Step 5 — Diagnose Common Causes

High CPU Usage

If the server is running but extremely slow or unresponsive, high CPU usage is a common cause:

top -bn1 | head -20

Look for processes consuming 90-100% CPU. Common culprits include:

• Runaway application processes
• Database queries that are stuck in loops
• Cryptocurrency mining malware (if the server was compromised)
• Excessive log processing

Out of Memory (OOM)

When the server runs out of RAM, the Linux OOM killer terminates processes to free memory, which can kill your web server or database:

# Check current memory
free -h
Check for OOM events in logs
dmesg | grep -i "out of memory"
journalctl | grep -i "oom"

If memory is the issue, either optimize your applications' memory usage or upgrade to a plan with more RAM.

Disk Full

A full disk can prevent services from starting, logs from being written, and databases from functioning:

df -h

If any filesystem shows 100% usage, you need to free space immediately. See Disk Full — How to Free Space.

Firewall Blocking Traffic

A misconfigured firewall can block all incoming connections:

# Check iptables rules
iptables -L -n
Check ufw status (Ubuntu)
ufw status
Check firewalld (CentOS/AlmaLinux)
firewall-cmd --list-all

If you recently changed firewall rules, consider reverting the changes. If you are locked out via SSH, use the web console to fix the firewall configuration.

Network Configuration Issues

Check that the network is properly configured:

# Check IP address assignment
ip addr show
Check default gateway
ip route show
Test outbound connectivity
ping -c 3 8.8.8.8

If the network interface has no IP address or the default gateway is missing, the server's network configuration may need to be reset. Contact support if you cannot resolve this.

Service Crashed

The specific service you are trying to access (web server, SSH, database) may have crashed while the server itself is running:

# Check web server status
systemctl status nginx
systemctl status apache2
Check SSH status
systemctl status sshd
Restart a crashed service
systemctl restart nginx
systemctl restart sshd

Check the service logs for error messages that indicate why the service crashed:

# Nginx error log
tail -50 /var/log/nginx/error.log
Apache error log
tail -50 /var/log/apache2/error.log
System journal for a specific service
journalctl -u nginx --since "1 hour ago"

Step 6 — Check for Data Center Maintenance

Occasionally, planned or emergency maintenance at our data centers can affect server availability. Check:

Step 7 — Contact Support

If you have gone through all the steps above and the server is still unresponsive, it is time to contact support:

Our support team has access to infrastructure-level diagnostics that can identify issues beyond what is visible from inside the server.

Prevention Tips

To minimize the risk of future outages:

• Set up monitoring. Use the built-in monitoring in your Data Mammoth dashboard or external monitoring tools to get alerted when your server becomes unresponsive.
• Enable automated backups. Backups let you quickly restore a working state if something goes wrong.
• Keep your system updated. Regular security updates reduce the risk of vulnerabilities that could lead to crashes.
• Right-size your server. If you are consistently hitting resource limits, upgrade to a larger plan. See How to Choose the Right VPS Plan.
• Configure a firewall carefully. Always test firewall changes before applying them permanently, and keep a web console session open as a backup when modifying rules.

Related Articles

• Cannot Connect via SSH — Troubleshooting
• High CPU Usage — Diagnosis & Fix
• Disk Full — How to Free Space
• How to Connect to Your Server via SSH