Skip to content
Website Rescue Rescue

Hosting Problems

Website Is Down

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Direct answer

When a website is down, triage in order: DNS resolution, hosting/origin uptime, application errors (WordPress/PHP), then CDN/edge — confirm the failure from more than one location before changing random settings.

“Website is down” is a symptom, not a diagnosis. Visitors may fail at DNS, at the host, inside WordPress, or at a CDN in front of a healthy origin. This guide gives a safe triage order so you identify which layer is broken, capture proof for your host, and avoid “fixes” that make a working layer worse.

Intermediate

What the error means

A site feels “down” whenever browsers cannot complete a useful page load. That can be ERR_NAME_NOT_RESOLVED (DNS), connection timeouts or refused (host/network), HTTP 5xx (origin or gateway), a WordPress critical error or white screen (application), or an edge/CDN error while the origin still answers on a direct hostname. Good triage separates those layers with simple checks: does the name resolve, does the origin IP respond, what status code returns, and do other cities see the same outage. Guessing — flushing everything, changing nameservers, and editing wp-config at once — mixes evidence and prolongs downtime.

Common symptoms

  • Browsers show connection errors, blank pages, or host/CDN error screens
  • Site works for you but not for customers (or the reverse) depending on region or ISP
  • Online uptime checkers disagree with your office network
  • wp-admin fails along with the front end, or only one of the two is unreachable
  • Domain resolves to an unexpected IP after a host or DNS change
  • Phone hotspot loads the site when office Wi‑Fi does not (local DNS/firewall issue)
  • Email or subdomain still works while the main site hostname fails (narrow DNS/app fault)

Most likely causes

  1. 01 DNS misconfiguration, expired domain, or nameserver change still propagating
  2. 02 Origin host down, overloaded, suspended, or firewall blocking traffic
  3. 03 WordPress/PHP application fatal, database outage, or maintenance mode
  4. 04 CDN/proxy mispointed, SSL mode mismatch, or edge outage in front of a live origin
  5. 05 Local ISP, corporate firewall, or stale resolver cache affecting only some users
  6. 06 SSL/certificate failures that some browsers treat as a hard block
  7. 07 Recent migration leaving DNS TTL pointed at the old server

What changed before the problem started

  • Hosting migration, DNS nameserver change, or domain renewal lapse
  • CDN enabled, SSL mode changed, or firewall rules tightened
  • Plugin/theme/core update or PHP version change on the origin
  • Host suspension, billing failure, or resource-limit lock
  • Deploy, backup restore, or staging push to production
  • Regional network incident reported by your ISP or CDN status page

Troubleshooting steps

  1. 01

    Confirm the outage from two networks and an external checker

    Try the site on office Wi‑Fi and on a phone cellular connection. Use a reputable multi-location uptime or HTTP checker against your exact hostname. Success signal: you know whether the failure is global, regional, or only on your LAN — which decides DNS vs host vs local firewall next.

  2. 02

    Verify DNS resolves to the expected hosting IP

    Look up A/AAAA (and CNAME) records for the apex and `www`. Compare them to the IP your host panel lists. If the domain is expired or nameservers are wrong, fix DNS/registrar first — WordPress edits will not help. Success signal: public DNS matches the current host’s documented IP.

  3. 03

    Test origin health separately from the CDN

    If Cloudflare or another CDN is proxied, check the host’s direct URL/IP or briefly set DNS-only for a controlled test. Note whether origin returns 200, 5xx, or connection failure. Success signal: you know if the edge or the origin is the broken hop.

  4. 04

    Read the exact browser or HTTP error

    Capture the status code or Chrome error (`ERR_CONNECTION_TIMED_OUT`, `ERR_NAME_NOT_RESOLVED`, 500/502/503, Cloudflare 5xx). Follow the matching server-error or Cloudflare guide once the code is known instead of treating every outage as “hosting is broken.” Success signal: a named error code written down with a screenshot.

  5. 05

    Check host panel status, suspension, and application logs

    Open the hosting dashboard for outage banners, suspension, disk-full, or MySQL-down notices. If the server is up, skim today’s error log for PHP fatals or database connection failures. Success signal: either a host-side incident ticket or a specific application fault to isolate.

  6. 06

    Stabilize WordPress only after network and host layers look healthy

    When origin responds but WordPress shows critical error, white screen, or DB connection errors, use those guides: recovery mode, plugin rename, or database credentials. Do not rename plugins while DNS still points at the wrong server. Success signal: origin IP serves WordPress again after the app-level fix.

When to stop troubleshooting

Hand off if the domain/DNS is locked at the registrar, the host confirms a datacenter outage you cannot influence, you lack panel and DNS access, malware suspension blocks the account, or revenue traffic has been dark longer than your maintenance window. Bring multi-location proof and the exact error code when you dispatch.

Information to collect before requesting help

  • 01 Exact browser message or HTTP status code with screenshot
  • 02 Results from at least two networks plus an external checker
  • 03 Current DNS A/AAAA/CNAME values vs host-documented IPs
  • 04 Whether a CDN is proxied and how origin responds directly
  • 05 Host panel notices: suspension, outage, disk, or database alerts
  • 06 What changed in the last 24–48 hours (DNS, host, CDN, updates)
  • 07 Registrar, DNS host, web host, and CDN account names

How a professional repairs the problem

A technician triages DNS → origin → application → CDN with multi-location checks, restores the broken layer only (DNS cutover, host unsuspend/restart, WordPress isolation, or edge SSL/proxy correction), verifies the hostname from multiple resolvers, and leaves a short note on which layer failed so the next incident starts faster.

Frequently asked questions

Why is the site down for customers but fine on my laptop? +
Often DNS propagation, local cache, regional CDN routing, or an office firewall. Always verify with a second network and an external checker before assuming the origin is healthy worldwide.
Should I change nameservers immediately? +
Only if authoritative DNS is wrong or the domain points at a dead host. Changing nameservers during an application outage adds propagation delay on top of the real problem.
Is every outage a hosting failure? +
No. DNS, CDN, SSL, WordPress fatals, and local network issues all present as “the site is down.” Triage the layer before blaming the host.
How long should I wait for DNS propagation? +
Follow the record TTL and your DNS host’s guidance. Many changes show up in minutes on some resolvers and longer on others — staggered results are normal until TTLs expire.
Can a plugin update take the whole site down? +
Yes, via PHP fatals or resource exhaustion — but confirm the origin is reachable and returning an application error first. If the connection never reaches WordPress, plugin isolation will not help.
What should I send my host in a downtime ticket? +
Timestamps, status codes, resolved IPs, multi-location checker links or screenshots, and whether CDN bypass still fails. That package skips the “works for us” loop.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.