The goal in the first few minutes is to confirm what's broken and isolate the layer before you start making changes. Run through these in order.
Step 1: Confirm the outage is real
Check from another device and a different network before anything else. What looks like a site outage is sometimes a local DNS cache, a browser issue, or a network block. If you have uptime monitoring configured, check it now — you'll know immediately whether the issue is real and roughly when it started.
- Open in a different browser or on your phone
- Switch from WiFi to mobile data (or vice versa)
- Ask someone in a different location to test
- Check a public tool like downforeveryoneorjustme.com
Step 2: Define the scope
Find out what is broken. Is the whole site offline, or is it one page, one subdomain, or one specific feature? A partial outage usually points to the application layer. A total outage — no pages loading at all — points toward DNS, hosting, or SSL.
Step 3: Check DNS
If the domain is unreachable rather than returning an error, DNS is worth checking early. Use dig or a public DNS lookup to confirm the domain resolves to the right IP. A recently changed DNS record — or an expired domain — can make a site disappear entirely.
dig yourdomain.com +short
nslookup yourdomain.comStep 4: Check SSL
If visitors are seeing browser security warnings rather than a blank page, SSL is the issue. Check the certificate's expiry date and confirm it covers the exact domain being accessed (including the www subdomain if relevant). An expired or mismatched cert causes modern browsers to block the page entirely, which looks like downtime.
Step 5: Check server reachability
If DNS resolves correctly and SSL isn't the problem, check whether the server responds. A connection timeout (no response at all) and a 502 or 503 (server reached but application failing) point to different layers. A timeout suggests the hosting layer; a 5xx suggests the application or a proxy in front of it.
Step 6: Check recent changes
Recent changes are the most common cause of sudden outages. Check git history, deployment logs, and any CMS plugin or theme updates applied in the last few hours.
- Code or configuration deployment
- CMS plugin or theme update
- Container or server restart
- Firewall, proxy, or CDN configuration change
- DNS record or SSL certificate update
Step 7: Check application health
A server can be fully reachable while the application itself is failing. Check your error logs for exceptions, look for failed database connections, and confirm that background workers and queue processors are running. Application-layer failures are rarely visible from the outside until users start reporting errors.
Step 8: Check dependencies
If your application depends on third-party services — payment processors, authentication platforms, CDNs, email providers — a failure upstream can bring down functionality that looks like your site. Check status pages for services your application calls. Most major providers publish one.
Step 9: Communicate
Even before the root cause is confirmed, let the people who need to know that you're aware and investigating. Internal teams can stop duplicating effort. If it's customer-facing, a status page update prevents a flood of support tickets. Short and honest is better than nothing while you diagnose.
How monitoring changes this
A good uptime monitor skips steps 1 and 2 entirely. It catches the outage automatically, records when it started, and tells you immediately whether the issue is a connectivity failure, an SSL problem, or something else. ServerVisor monitors uptime, SSL certificates, and domain expiration in one place, and sends alerts the moment something fails — so by the time you open this checklist, you already know what layer to start at.