Website Status Checker

Run the URL through an external status checker that tests from servers outside your network. If it loads from external locations, the issue is local — your ISP, DNS cache, browser extension, or firewall. If multiple external locations also report it down, then the site is genuinely offline. Tools like DownDetector also crowd-source reports from real users, which helps confirm a wider outage. I always check from at least two independent tools before reporting an outage to a client — false alarms damage credibility.

503 means Service Unavailable — the server understood the request but can't process it right now. Usually it's temporary: maintenance mode, server overload, or an upstream backend down. Many systems return 503 with a Retry-After header indicating when to try again. Cloudflare and other CDNs also return 503 when the origin is unreachable. Don't confuse it with 500 (generic server error) or 504 (gateway timeout). 503 tells you to wait and retry — repeated 503s for hours mean the issue is not actually temporary.

Use a tool that measures TTFB (Time To First Byte), full page load, and server response time separately. Most status checkers show response time alongside the HTTP status. For deeper analysis, WebPageTest or Lighthouse give waterfall views showing each request's timing. Compare response times across multiple regions to spot geographic latency issues. Anything over 800ms TTFB is slow; over 2 seconds is a problem. Slow response time often indicates server overload, database issues, or missing CDN — and it directly hurts SEO.

Local issues, almost always. Check in this order: try a different browser to rule out cache or extensions, try a different network (mobile data instead of WiFi) to rule out ISP routing or DNS, flush local DNS cache, and try from a different device. Geo-blocking by the site or your IP being on a blocklist can also cause this. Run an external status check — if it returns 200 OK from external servers, the site is fine and your local environment is the problem.

Set up automated monitoring with Uptime Robot, Pingdom, StatusCake, or Better Uptime. Configure 1-minute check intervals from multiple geographic regions, alert thresholds (status code, response time, content match), and notification channels (email, SMS, Slack, PagerDuty). For business-critical sites, track SLA metrics monthly. I tell my team to also monitor specific transactions — homepage loading isn't enough, you need to know if checkout, login, or search work too. Synthetic monitoring on key user flows catches issues actual users would hit first.

Generic server-side failure. Common causes: PHP errors or fatal exceptions, database connection failures, exceeded memory limits, misconfigured .htaccess or nginx config, broken plugin or theme update (very common in WordPress), exhausted disk space, or backend service crashes. Check server error logs first — they almost always reveal the actual cause. /var/log/nginx/error.log, /var/log/apache2/error.log, or your application's log file. 500 is a symptom, not a diagnosis; never tell a client "it's a 500 error " without explaining what actually broke.

Submit the exact URL to a status checker — copy-paste it, don't retype, because trailing slashes and case sensitivity matter. Check the response code in the result. A real 404 returns status 404 with a 404 page. Watch for "soft 404s " — pages that show error content but return 200 status, which confuses search engines. Also check whether 404 should actually be 410 (Gone, permanent) or 301 (redirected to a relevant new URL). For SEO health, 404 logs should be reviewed monthly to catch broken internal links.

Yes, and it's one of the most common "site is down " scenarios that isn't actually downtime. Broken A or AAAA records, wrong nameservers, DNSSEC validation failures, or stale resolver caches can all prevent the site from resolving — even though the server is running fine. To rule this out, ping the domain (no IP returned = DNS issue), then ping the actual IP directly (if that works, it confirms DNS is the problem). Always check DNS before assuming server downtime — saves a lot of unnecessary panic.

Run a full post-migration audit: confirm the homepage and key inner pages return 200, redirect mappings work correctly (old URLs 301 to new), DNS resolves to the new server everywhere globally, SSL certificate is valid on the new host, MX records still point to the right mail servers, response time is acceptable, and Search Console hasn't flagged crawl errors. I keep a 25-point post-migration checklist for every client. Skipping this step is how migrations look successful on day one and catastrophic by week two.

Timeout means the tool sent a request but didn't get a response within its configured wait time — usually 10–30 seconds. Causes vary: server hung or crashed, network congestion, firewall silently dropping packets (no rejection, just no reply), DNS not resolving, or origin overwhelmed. Timeout is different from a clean error — there's no response code, just silence. To diagnose, try from a different region, traceroute to see where packets stop, and check server logs to see if requests even arrive at the application layer.