--- title: "Why is my website down? | Logdash" description: "The common website down reasons, how to tell which one you have from the error you see, a copy-paste diagnosis script, and how to hear about the next outage first." url: https://logdash.io/learn/why-is-my-website-down --- # Why is my website down Most outages come from six causes: a bad deploy, a crashed app or database, a full disk, an expired domain or SSL certificate, a broken DNS record, or your host having its own outage, and the error you see already narrows it to one or two. Start with what changed. Outages without a cause are rare, outages whose cause nobody remembers are common. A deploy 20 minutes ago, a DNS edit yesterday, a card that expired last month on the account that pays for the domain. Then read the error, because the error already rules out most of the list. ## Website down reasons, by the error you see - 502 Bad Gateway or 504 Gateway Timeout: the proxy or CDN is up and the app behind it is not. A crashed process, an out-of-memory kill, or a deploy that never started listening. - 500 Internal Server Error: the app runs but throws. Usually the last deploy or a database it cannot reach. The logs from that minute name it. - 503 Service Unavailable: the host, the load balancer or your own health check says it cannot serve. Check your provider status page before your code. - Could not resolve host, or DNS\_PROBE\_FINISHED\_NXDOMAIN in Chrome: the name points nowhere. An expired domain or a broken DNS record. - "Your connection is not private": the SSL certificate expired or does not match the name. Auto-renewal fails silently more often than anyone admits. - Connection refused or a timeout: the server is off, the port is closed, or a firewall drops you. A full disk ends here too, once the app cannot write and stops answering. ## Find out which one in a minute ```bash SITE=example.com # Status code, time, and the IP the request actually went to curl -sS -o /dev/null -w '%{http_code} in %{time_total}s from %{remote_ip}\n' "https://$SITE" # Does the name resolve? Empty output means DNS. dig +short "$SITE" # When does the SSL certificate expire? echo | openssl s_client -connect "$SITE:443" -servername "$SITE" 2>/dev/null \ | openssl x509 -noout -enddate # When does the domain expire? whois "$SITE" | grep -i 'expir' ``` A status of 000 means curl got no HTTP answer at all, and the line it prints above says why. An empty dig answer means DNS. A notAfter date in the past means the certificate. An expiry date in the past means renew the domain before anything else. ## Why is my website down for me but not others If the site loads on your phone over mobile data but not on your laptop, the site is fine. The usual suspects: your resolver still caching an old IP after a migration, a firewall or WAF rule that blocked your IP after too many requests, a VPN exit the host refuses, or a browser holding a cached 301 to a dead URL. Flush DNS, try a private window, turn the VPN off, in that order. ## Why is my website not loading but not down A 200 that takes 9 seconds is an outage to the user and a green tick to most monitors. Slow pages come from a query without an index, a connection pool at its limit, or a third-party script that blocks rendering. Watch response time, not only status. A check that went from 200 ms to 4 seconds over a week is telling you something before anything goes down. Logdash records the response time of every check and counts anything slower than 10 seconds as down. ## Hear about the next one from a monitor 1. **Add the URL** Create a service in Logdash and point it at the site or its health route. Every 5 minutes on the free plan, every minute on Builder, every 15 seconds on Pro. 2. **Connect Telegram** Add a Telegram channel once and attach it to the monitor. The bot confirms the setup with a welcome message. 3. **Break it once** Stop the app for one check. The monitor flips to down and a Telegram alert reaches your phone with the status code and the error, so the first line of your diagnosis arrives with the alert. Every cause on this list ends as a failed HTTP check, so the monitor catches all of them once they happen. It does not warn you before a certificate or a domain expires. It tells you on the first check that fails because one did. ### Why is my website down for me? If it loads on mobile data, the problem is your side: a cached DNS answer, a firewall rule that blocked your IP, a VPN, or a cached redirect in the browser. Flush DNS, open a private window and turn off the VPN. ### Why is my website not loading? Read the error first. 502 or 504 means the app behind the proxy died, 500 means the app throws, a DNS error means the name points nowhere, and a privacy warning means the certificate. A blank page that spins is usually slowness, not an outage. ### What are the most common website down reasons? A bad deploy, a crashed app or database, a full disk, an expired domain or certificate, a broken DNS record, and the hosting provider having an outage. The first two account for most of the incidents a small team sees. ### Why is my website down after a deploy? Usually the new build never started listening, a migration did not run, or an environment variable is missing. The logs from the first minute after the deploy name it. Roll back first, read the logs second. ## Keep reading [All uptime monitoring explainers](https://logdash.io/learn): Fourteen uptime questions, each answered in one sentence, then the math or the command behind it. [MTTR](https://logdash.io/learn/mttr): MTTR is the average time it takes to get a broken service working again: add up the downtime from every incident and divide by the number of incidents, so four outages of 12, 47, 6 and 31 minutes give an MTTR of 24 minutes. [Open source website monitoring](https://logdash.io/learn/website-monitoring-open-source): Open source website monitoring means a checker whose code you can read and run yourself: Uptime Kuma or Gatus if you want to host it, Upptime if you want GitHub Actions to run it, and Logdash if you want the code open but the monitor run for you. [Best self hosted uptime monitor](https://logdash.io/learn/best-self-hosted-uptime-monitor): Uptime Kuma is the best self hosted uptime monitor for most people, Gatus is better if you want your checks in a YAML file in git, Upptime is better if you want no server at all, and Logdash cannot be self-hosted in production with one command yet. [Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.