--- title: "Site Down" --- # 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. ```bash ping your_server_ip ``` A reachable node responds like this: ```bash 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. :::info Note ICMP may be disabled even when the server is up — a ping failure is not conclusive. Always also try SSH. ::: Try SSH: ```bash ssh username@xx.xx.xx.xx ``` If SSH fails, the node is likely down or hung. See [Node Not Accessible](./node-not-accessible.md). ## 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](/docs/myaccount/node/features/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: - [High CPU Load Troubleshooting](./high-cpu-load.md) - [Disk Space Troubleshooting](./disk-space.md) ## 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:** ```bash /var/log/apache2/error.log /var/log/apache2/access.log ``` **Apache on RHEL / CentOS (httpd):** ```bash /var/log/httpd/error_log /var/log/httpd/access_log ``` **Nginx:** ```bash /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: ```bash tail -f /var/log/nginx/access.log tail -f /var/log/httpd.log ``` Or page through the full log: ```bash 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):** ```bash service apache2 status service apache2 start service apache2 stop service apache2 restart service apache2 reload ``` **Apache (httpd):** ```bash service httpd status service httpd start service httpd stop service httpd restart service httpd reload ``` **Nginx:** ```bash 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:** ```bash apache2ctl -t httpd -t ``` **Check Nginx syntax:** ```bash 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: ```bash service mysql status service mysqld status service mongod status ``` Or verify the listening port directly: ```bash netstat -ntlp | grep mysql ``` A healthy MySQL listener looks like: ```bash 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: ```bash 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**). ```bash telnet your_server_ip 80 telnet your_server_ip 443 ``` An open port produces output like: ```bash 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: ```bash 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](./security.md) 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. ```bash dig A example.com +short ``` Expected output is the IP of your node: ```bash 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](mailto:cloud-platform@e2enetworks.com). ## Related Resources - [Node Not Accessible](./node-not-accessible.md) - [High CPU Load](./high-cpu-load.md) - [Disk Space Issues](./disk-space.md) - [Network Troubleshooting](./network.md) - [Security Troubleshooting](./security.md) ---