Why Is My Website Down? 12 Causes and How to Diagnose Each

When a website stops loading, the instinct is to refresh and hope. A better approach is to work out which layer of the stack is failing, because every layer leaves different evidence. This guide gives you a fixed order of checks, twelve concrete causes with the symptoms that identify them, and a clear point at which to stop digging and contact your host.

You do not need root access for the first half. Most of the diagnosis is done from the outside, with a browser, curl and a few lookups.

Start with the request path

A page view is a chain of steps, and the site is "down" if any one of them breaks:

1. DNS turns the hostname into an IP address.
2. The network carries a TCP connection to that address.
3. TLS negotiates encryption (for HTTPS).
4. A front end (CDN, load balancer, reverse proxy) accepts the request.
5. The web server (nginx, Apache, IIS) receives it.
6. The application (PHP, Node, Python, a CMS) builds the response.
7. The database and other backends supply the data.

The error you see tells you how far the request got. A DNS error means it never left step 1. A connection timeout means step 2. A 5xx status code means steps 1 to 4 worked and something behind them failed. That is why the very first move is to look at the exact symptom rather than the word "down".

A five-minute triage

Run these in order and stop when one gives you an answer.

# 1. Does the name resolve, and to what?
dig +short example.com A
dig +short example.com AAAA

# 2. Does anything answer on the web ports?
nc -vz example.com 443
nc -vz example.com 80

# 3. What does the server actually say?
curl -sS -o /dev/null -D - https://example.com/ | head -n 20

If you would rather not use a terminal, the वेबसाइट हेल्थ चेक और HTTP स्टेटस चेकर run equivalent tests from outside your own network, which also settles whether the problem is the site or your connection. If only you can see the failure, read Is a website down for everyone or just me?.

The 12 most common causes

1. DNS records are wrong, missing or not yet propagated

Symptom: ERR_NAME_NOT_RESOLVED, "server not found", or the site loads for some people and shows an old host for others.

Check: dig +short example.com and compare against the IP your host gave you. Query your nameservers directly with dig @ns1.yourdns.com example.com to see the authoritative answer. The DNS चेकर shows what different resolvers return.

Typical causes: a record deleted by mistake, a migration pointed at the wrong IP, or nameserver changes that are still propagating. Cached answers live as long as the record's TTL, which is why DNS propagation looks inconsistent.

2. The domain expired or was suspended

Symptom: Everything resolves to a registrar parking page, or does not resolve at all.

Check: the WHOIS लुकअप shows expiry date and status flags such as clientHold or redemptionPeriod. Renewal lapses are surprisingly common because the card on file expires. See domain expiry, grace and redemption periods for what you can still recover.

3. The server or hosting account is offline

Symptom: Connection timeout on both ports 80 and 443, ping or traceroute dies at the hosting network.

Check: log in to your provider's panel and look at the instance state and any incident banner. A VPS that was stopped, a cloud instance that failed a host health check, or an account suspended for non-payment all look identical from outside. If the machine is up but unreachable, try the provider's web console.

4. The web server process has crashed or stopped

Symptom: ERR_CONNECTION_REFUSED. The host is reachable, but nothing listens on the port.

sudo systemctl status nginx      # or apache2 / httpd
sudo ss -tlnp | grep -E ':80|:443'
sudo nginx -t                    # validate config before restarting
sudo journalctl -u nginx --since "30 min ago"

A failed reload after a config edit is the classic trigger: the old process keeps running until a restart, then the broken config prevents it coming back. See connection refused, timed out and reset explained.

5. The application layer is failing

Symptom: A 500, 502, 503 or 504 response, or a blank white page.

The web server is alive but the PHP-FPM pool, Node process or Python worker behind it is not behaving. Look at the application log, not just the web server access log. For specifics, see the dedicated guides for 500, 502, 503 और 504.

6. The database is down or exhausted

Symptom: WordPress shows "Error establishing a database connection"; other apps log "too many connections" or "server has gone away".

sudo systemctl status mysql      # or mariadb / postgresql
mysqladmin -u root -p status
sudo journalctl -u mysql --since "1 hour ago"

MySQL and MariaDB are frequent victims of the kernel's out-of-memory killer, so check dmesg -T | grep -i "killed process" as well.

7. The machine ran out of a resource

Symptom: Everything gets slow, then fails. Intermittent 502/504 errors, SSH that hangs, services dying without a clear reason.

df -h          # disk space
df -i          # inodes (full inodes also stop writes)
free -m        # memory and swap
uptime         # load average vs. CPU count

A full disk is the most underrated cause. Log files, backups and temporary uploads silently fill a volume, then the database and PHP sessions fail to write. On shared hosting you may instead hit a per-account CPU, memory or process limit, which usually produces 503 or 508-style pages.

8. A bad deploy or configuration change

Symptom: Failure begins at a precise time that matches a code push, plugin update, PHP upgrade or config edit.

This is the most common cause on well-run sites, and the best fix is boring: roll back first, investigate afterward. Check version control history, your hosting panel's PHP version setting, and the application error log for fatal errors or missing extensions.

9. The TLS certificate expired or is misconfigured

Symptom: Browsers show a full-page warning (NET::ERR_CERT_DATE_INVALID), API clients fail with handshake errors, but the server is otherwise healthy.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer

The SSL Checker reports expiry and chain problems. Automated renewal fails more often than people expect, usually because a DNS challenge record or port 80 rule changed. See how to renew and automate SSL.

10. The CDN or reverse proxy cannot reach your origin

Symptom: The error page carries the CDN's branding, or you see Cloudflare 52x codes.

The edge is up; the connection from edge to your server is not. Allow-listing, SSL mode mismatches and origin timeouts are the main culprits. See Cloudflare 520 to 526 errors explained and the Cloudflare एरर चेकर.

11. A firewall, rate limit or security tool is blocking traffic

Symptom: The site works from a mobile network but not from your office, or monitoring probes get 403 or timeouts while real users are fine.

Possible sources include a host firewall (ufw status, iptables -S), fail2ban banning an address after repeated login attempts, a WAF rule, or a hosting provider's DDoS mitigation that has nulled-routed an IP. The Blacklist Checker is useful if you suspect your own IP was listed, and What Is My IP tells you which address you are presenting.

12. Compromise, abuse or a dependency outside your control

Symptom: Unfamiliar files, unexpected redirects, a hosting suspension notice citing abuse, or a third-party service (payments, fonts, a login provider) stalling page loads.

If you suspect compromise, take the site offline deliberately, preserve logs, and restore from a known-clean backup after changing every credential. For third-party dependencies, load the page with the browser's network tab open and look for requests that never finish.

Matching symptoms to causes

Find the time of failure

Almost every outage has a trigger. Ask what changed in the last hour or day: a deploy, a plugin or OS update, a certificate renewal, a DNS edit, a traffic spike from a campaign, a scheduled backup that saturated the disk. The web server error log, journalctl --since, your hosting panel's activity log and your registrar's change history all carry timestamps. Lining them up often reveals the cause in minutes.

When to contact your host

You can resolve most causes above yourself, but escalate quickly when:

• The server is unreachable and the provider's console or panel also shows it as unhealthy.
• You are on shared or managed hosting and a service you cannot restart (web server, MySQL) is down.
• Disk, memory or process limits are being hit and you cannot see what is consuming them.
• You suspect a network issue upstream, for example mtr showing loss inside the provider's network.
• The account is suspended or flagged for abuse.

Send them something they can act on: the exact URL, the exact error text, the time it began with a timezone, the output of curl -I, and what you have already ruled out. "My site is down" gets a generic reply; "port 443 times out from three networks, port 22 works, started at 09:12 UTC" gets an engineer.

Stop being the monitoring system

If you only find out because a customer emails you, the real defect is detection. A basic external check that requests a page every minute or few minutes and alerts by email or chat will shorten outages more than any tuning. The अपटाइम मॉनिटर covers that, and how often you should monitor a website explains how to choose an interval. Afterwards, write down what happened using the incident postmortem template so the same failure does not repeat.

अगले कदम

Related tools and guides:

• वेबसाइट हेल्थ चेक for a quick external test of DNS, TLS and response
• HTTP स्टेटस चेकर to see the exact status code returned
• Is a website down for everyone or just me?
• Connection refused, timed out and reset explained
• Uptime monitoring for small business

सामान्य प्रश्न

How can I tell whether my website is down or just my connection?

Test the site from a different network, such as a phone on mobile data, and use an external checker that is not on your network. If it loads there, the issue is local: your DNS cache, VPN, ISP route or a hosts-file entry. If every vantage point fails, the problem is with the site or its hosting.

Why does my site work for me but not for customers?

Common reasons are DNS propagation differences, a CDN node serving a bad response, a regional firewall rule, or a certificate chain that your browser has cached but other clients cannot build. Logged-in users may also bypass a cache that is broken for anonymous visitors.

How long does an outage usually last?

There is no reliable typical figure; it depends entirely on the cause. A stopped service can be fixed in a minute, an expired domain in hours, and a corrupted database restore in much longer. What matters most is how quickly you detect it and whether you have a tested rollback or backup.

Can slow performance cause a website to go down?

Yes. When requests take longer than the proxy or PHP timeouts, users get 504 errors, and when workers are all busy new requests queue or are refused with 503. Slowness and downtime are often the same problem at different stages.

Should I restart the server first?

A restart clears memory pressure and stuck processes, but it also destroys the evidence, such as which process was consuming memory. Capture logs, free -m, df -h and the top processes first, then restart if you need service back quickly.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.