Skip to main content

Troubleshooting Steps When Your Site is Down

If you have a Webcheck alert configured for your site, you will be notified when:

  • The site is DOWN (the URL returns no response or a non-200 status code).
  • The site loads very slowly — by default, when the response takes more than 60 seconds. This is controlled by the Timeout setting.

When you receive a site-down alert, the goal is to isolate which layer of the stack failed: the node, the web server, the application config, the database, the network ports, or the DNS pointing at the site. The steps below walk through each layer in order.

Step 1: Check the Server Status​

Before anything else, verify the node itself is up. Try ping and then SSH.

ping your_server_ip

A reachable node responds like this:

e2e@compaqlaptop:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=18.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=21.3 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 18.042/19.837/21.342/1.362 ms

If ping fails, check the server console for errors and restart the node from MyAccount.

Note

ICMP may be disabled even when the server is up — a ping failure is not conclusive. Always also try SSH.

Try SSH:

ssh username@xx.xx.xx.xx

If SSH fails, the node is likely down or hung. See Node Not Accessible.

Step 2: Monitor Server Resources​

A maxed-out server can become unresponsive even when it is technically running. Use the Monitoring tab in MyAccount or Node Monitoring and Alerts to check CPU, memory, and disk for the period of the outage. If you find anomalies (memory exhaustion, CPU pinned at 100%, disk full), see:

Step 3: Check the Logs​

The web server log is almost always the fastest way to identify the root cause. Logs live under /var/log/:

Apache on Ubuntu / Debian:

/var/log/apache2/error.log
/var/log/apache2/access.log

Apache on RHEL / CentOS (httpd):

/var/log/httpd/error_log
/var/log/httpd/access_log

Nginx:

/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/nginx/nginx_error.log
/var/log/nginx/access_error.log

Tail the latest entries:

tail -f /var/log/nginx/access.log
tail -f /var/log/httpd.log

Or page through the full log:

less /var/log/nginx/access.log

If you have configured custom log paths, check those instead.

Step 4: Make Sure the Web Server is Running​

Check service status. If it is not running, start it.

Apache (apache2):

service apache2 status
service apache2 start
service apache2 stop
service apache2 restart
service apache2 reload

Apache (httpd):

service httpd status
service httpd start
service httpd stop
service httpd restart
service httpd reload

Nginx:

service nginx status
service nginx start
service nginx stop
service nginx restart
service nginx reload

Step 5: Verify the Web Server Configuration Syntax​

If the web server fails to start after a config edit, the config almost certainly has a syntax error.

Apache configuration directories:

  • Debian / Ubuntu: /etc/apache2/
  • Fedora / CentOS: /etc/httpd/

Nginx configuration directory:

  • /etc/nginx/

Check Apache syntax:

apache2ctl -t
httpd -t

Check Nginx syntax:

nginx -t

If the output is Syntax OK or test is successful, the file is valid. test failed means an invalid directive exists — the error message will name the file and line. Fix it and re-run the check before restarting.

Step 6: Check the Database Backend​

If the site depends on a database (MySQL, PostgreSQL, MongoDB, etc.), confirm the database service is running:

service mysql status
service mysqld status
service mongod status

Or verify the listening port directly:

netstat -ntlp | grep mysql

A healthy MySQL listener looks like:

tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 3356/mysqld

Step 7: Confirm the Web/App Server Can Reach the Database​

Even when the web server and database are both running, the application can still fail if it cannot authenticate or connect.

For a WordPress site, the connection settings live in wp-config.php. Verify DB_NAME, DB_USER, and DB_PASSWORD. Test the credentials directly:

mysql -hDB_Host -uDB_USER -pDB_PASSWORD

A successful login confirms the database accepts the credentials and is reachable. If it fails, the message will indicate whether the issue is credentials, hostname, or network.

Step 8: Make Sure the Required Ports are Open​

The web server typically listens on port 80 (HTTP) and 443 (HTTPS). The database listens on a separate port (MySQL default is 3306).

telnet your_server_ip 80
telnet your_server_ip 443

An open port produces output like:

e2e@compaqlaptop:~$ telnet xx.xx.xx.xx 80
Trying xx.xx.xx.xx…
Connected to xx.xx.xx.xx.
Escape character is ‘^]’.

If the application server and database are on different nodes, also verify the database port from the app server:

telnet your_database_server_ip 3306

If the ports are unreachable, check the security group and OS firewall — you may need to open 80, 443, or 3306. See Security Troubleshooting for the order of checks.

Step 9: Verify DNS​

If the site responds when you visit the public IP directly but not via the domain name, the DNS record is wrong or stale.

dig A example.com +short

Expected output is the IP of your node:

e2e@compaqlaptop:~$ dig A example.com +short
xx.xx.xx.xx

Also check the Apache virtual host file or the Nginx server block for the domain to confirm the server is configured to respond to requests for that hostname.

Conclusion​

Going through the layers in order — node, resources, logs, web service, syntax, database, ports, DNS — almost always isolates the issue. If you complete the steps above and the site is still down, contact cloud-platform@e2enetworks.com.

Last updated on May 15, 2026.