Add to Preferred Sources
A website down event is not a mystery — it is one of a handful of known failure layers: DNS, hosting, SSL, application code, or a security block. The fastest way to stop losing customers is to identify the layer in the first five minutes rather than firing off panicked calls in the wrong direction.
This triage checklist walks you through exactly that, in plain language, without requiring server access or a developer on speed dial. If you are still weighing whether your site is set up to survive an outage before it happens, start with what a website actually costs to run in South Africa — resilience is built into architecture decisions, not bolted on afterwards.
South African sites face a specific combination of risks: coordinated DDoS attacks hit local ISPs in 2026, load shedding threatens visitor connectivity even when the server stays up, and many businesses run on shared hosting without generator backup. If you have ever searched "why is my website down" at 9am with your phone ringing, this checklist is written for that moment.
Whether your site is website down for everyone globally or just failing locally matters enormously — the fix paths are completely different. If you already have monitoring in place, see our guide to website uptime monitoring for SA businesses — this post picks up where monitoring ends and the incident begins.
Quick Answer
When your website is down, open an incognito window on a different network and visit UptimeRobot's free website down checker or isitdownrightnow.com to confirm the outage is global. Note the HTTP error code you see — 5xx codes point to the server layer; DNS_PROBE errors point to DNS; SSL warnings point to a certificate. Then work the five-layer checklist below in sequence. Most incidents are diagnosed in under ten minutes once you know which layer to check.
Jump To
Step 1 — Confirm It Is Really Down
Decode the Error: The Triage Decision Table
Step 2 — DNS and Domain Checks
Step 3 — Hosting and Server Status
Step 5 — Application and Code Layer
Not Sure Which Layer Is Failing?
Send us your site URL and the error you are seeing — we will tell you which layer to check first and what to say when you call your host.
Get a Free Triage ReviewStep 1 — Confirm Your Website Is Actually Down for Everyone
The first step in any triage is separating a local issue from a genuine global outage — many apparent downtime events are DNS cache problems on a single device or a browser extension blocking the site.
- Open an incognito or private browser window. This bypasses cached DNS entries and browser extensions. If the site loads in incognito, the problem is local to your browser.
- Switch networks. Try your site on mobile data instead of your office Wi-Fi. If it loads on mobile data, your router or ISP may be the issue.
- Run a global check. Paste your URL into one of these free tools — no login required:
- UptimeRobot Is It Down — confirms downtime from a primary location with a second confirmation check; shows HTTP status code and response time, no login required
- Is It Down Right Now — instant, no account needed
- Pulsetic — tests from 15 locations simultaneously
What to look for: If the checker confirms the website is down for everyone globally, the problem is in the infrastructure — DNS, hosting, SSL, or your application. If it shows only you are affected, the problem is local: your DNS cache, your ISP, or your browser. In the first case, proceed to the triage table. In the second, flush your DNS cache and try from mobile data.
Decode the Error: The Website Down Triage Decision Table
The error code or browser message visible when your website is down is a direct pointer to the failure layer — reading it correctly saves you 30 minutes of guessing.
| What You See | Likely Layer | Fastest First Check | Who to Contact |
|---|---|---|---|
| DNS_PROBE_FINISHED_NXDOMAIN (Chrome) or "Server not found" | DNS | Log into domain registrar — check domain expiry and nameserver records | Domain registrar or DNS provider |
| Blank / no connection (checker returns no response) | DNS or SSL/TLS | Run free checker first; if confirmed down globally, check registrar for expired domain or lapsed nameservers | Domain registrar first; then host |
| SSL warning / "Your connection is not private" / HTTPS error | SSL Certificate | Check certificate expiry via Qualys SSL Labs (free, no login) | Hosting provider or SSL certificate authority |
| 500 Internal Server Error | Application / server config | Check hosting error logs; identify any plugin, theme, or code changes in the last hour | Developer or managed host support |
| 502 Bad Gateway | Server overload / proxy | Check host status page; check for traffic spike or memory limit breach in cPanel/dashboard | Hosting provider |
| 503 Service Unavailable | Server overload or maintenance | Check host status page for scheduled maintenance; check for traffic spike in analytics | Hosting provider |
| 504 Gateway Timeout | Slow upstream / database | Check database query logs; confirm no long-running processes via hosting panel | Hosting provider or developer |
| 403 Forbidden | WAF / firewall / file permissions | Check if Cloudflare or hosting firewall triggered a block; review recent plugin or .htaccess changes | Cloudflare dashboard or hosting provider |
Key Takeaway
5xx error codes (500, 502, 503, 504) always point to the server or application layer — your hosting provider or developer is the right call. DNS errors and blank screens point to your domain registrar. SSL warnings point to a lapsed or misconfigured certificate. 403 Forbidden usually points to a security rule, not your server being down.
Step 2 — DNS and Domain Checks When Your Website Is Down
DNS failure is one of the most common causes of a site appearing completely unreachable, and it is also one of the easiest to diagnose without developer access.
Check your domain expiry first. Log into your domain registrar (name.com, namecheap.com, afrihost.co.za, domains.co.za, or whoever manages your .co.za or .com). A lapsed domain registration takes the site offline instantly and visually looks identical to a server failure. Check the expiry date before anything else.
Verify nameserver records. If you recently moved hosting providers or enabled a CDN like Cloudflare, the nameservers pointing to your DNS provider may not have updated everywhere yet. DNS propagation — the time it takes for all ISPs globally to recognise a nameserver change — typically takes 24 to 48 hours; ISPs with longer cache refresh cycles can push this to 72 hours in edge cases. During propagation, some visitors see the site and others do not. This is normal behaviour, not a fault.
Check A records and CNAME records. Log into your DNS provider's dashboard and confirm the A record (which maps your domain to an IP address) matches your current hosting server's IP. If you recently migrated servers and the IP changed, an outdated A record will send visitors to a server that no longer hosts your site.
SA-specific note: South Africa's .co.za registry is managed through ZACR (ZA Central Registry). If your .co.za domain has expired, your registrar contacts you by email — check your spam folder first. Redemption periods apply after expiry, and recovery timelines vary by registrar — contact your registrar's support directly to confirm the fastest path back.
Step 3 — Hosting and Server Status
Hosting-layer failures cause a significant share of website downtime, covering everything from server hardware failure to traffic that exceeds your plan's resource limits. When your website is down and the DNS and SSL checks are clear, this layer is where to look next.
Check your host's status page immediately. Every reputable South African and international hosting provider maintains a live status page. Search "[your host name] status" or "[your host name] service status" — most publish real-time incident information. If your host is experiencing a regional or platform-wide outage, there is nothing to fix on your end; you wait or escalate to their support.
Check resource limits in your control panel. If your host's status page shows no incidents, log into cPanel, Plesk, or your hosting dashboard and check CPU usage, RAM, and concurrent connection counts. A 502 or 503 error often appears when a site exceeds its shared-hosting resource limits — either from a sudden traffic spike or from a rogue plugin consuming server memory.
Review recent changes. According to the Uptime Institute's 2022 Outage Analysis, human error caused 40% of significant outages — defined as those causing both downtime and financial loss — in the preceding three years. Most trace back to a plugin update, a settings change, or a deployment that ran on a Friday afternoon. Check your WordPress update log or deployment history for anything applied in the last 24 hours.
Useful habit: Keep a one-line change log for your site. Date, what changed, who made the change. When something breaks at 8am Monday, you know immediately whether Friday's plugin update is the suspect.
Step 4 — SSL Certificate Checks
An expired SSL certificate does not take your website offline — it blocks visitors from reaching it, which is effectively the same outcome from a revenue perspective.
When an SSL certificate expires, browsers display a full-screen warning ("Your connection is not private") that most visitors will not click through. The site remains on the server; the certificate is simply no longer valid. Check your certificate's expiry date using Qualys SSL Labs — free, no login — by entering your domain and reading the expiry date in the results.
Renew the certificate through your hosting provider or certificate authority. Many managed hosting plans include automatic Let's Encrypt renewal, but this is not universal — confirm with your specific provider and plan tier whether auto-renewal is active before assuming it is. Where auto-renewal is enabled, it still requires the domain to resolve correctly, meaning an unresolved DNS problem can prevent renewal and trigger an SSL failure as a downstream effect.
Key Takeaway
Set a calendar reminder 30 days before your SSL certificate expires. On hosting plans without auto-renewal, a lapsed certificate is a fully preventable cause of what looks like a complete outage. Most shared hosting plans include free Let's Encrypt SSL; if yours does not, ask why.
Running a WordPress Site Without Managed Maintenance?
Tell us your current setup — plugins, host, and update schedule — and we will flag the three maintenance gaps most likely to cause an unplanned outage.
Get a Free Maintenance ReviewStep 5 — Application and Code Layer
When my website is down with a 500 Internal Server Error or a blank white screen, the problem is in the application layer — your CMS, plugins, theme, or database — not the infrastructure beneath it. This is the layer most often broken by a recent update.
WordPress white screen / 500 error after an update. Log into WordPress admin (yourdomain.co.za/wp-admin) — if admin loads but the front end does not, the problem is almost certainly a plugin or theme. Go to Plugins → Installed Plugins and deactivate all plugins in bulk. If the site loads, reactivate plugins one by one to identify the conflict. If admin also returns a 500, access your hosting file manager or FTP and rename the /wp-content/plugins/ folder to /wp-content/plugins_old/ to force-deactivate all plugins.
Database connection errors. The "Error establishing a database connection" message in WordPress indicates the site cannot reach its database. This happens when the database server restarts, the connection pool is exhausted, or database credentials change during a server migration. Contact your hosting provider — most can restart the MySQL service or confirm credential issues within minutes.
Recent deployment errors. If you or a developer pushed code changes recently, roll back to the last known working version. If you have a staging environment, compare the staging configuration against production to identify discrepancies.
Common mistake: Updating WordPress core, theme, and five plugins simultaneously on a live site without a staging test. When something breaks, you have no way of knowing which of the six updates caused the conflict. Update one at a time, test each time.
SA-Specific Risks: Load Shedding and DDoS Attacks
South African website owners face two infrastructure risks that are less common in other markets and that require different responses from the standard triage flow above.
Load Shedding and Visitor Connectivity
South Africa recorded only 26 hours of load shedding through all of 2025, the longest run without blackouts in nearly a decade. The underlying infrastructure risk remains, however, given an ageing grid and a projected capacity gap through the late 2020s.
When load shedding occurs, the impact on a website is primarily on the visitor side, not the server. Reputable SA hosting providers run Tier 3 or Tier 4 data centres with generator and UPS backup, meaning the server itself stays up — a free website down checker confirming uptime from Johannesburg is consistent with this.
What drops is visitor connectivity: home routers lose power, mobile cell towers drain their battery reserves, and browsing becomes intermittent. If your analytics show a sudden traffic drop with no server-level errors during a scheduled outage window, visitor connectivity is the most probable explanation. For hosting architecture detail, see website load shedding and uptime in South Africa.
DDoS Attacks and WAF Blocks
In mid-2026, coordinated DDoS attacks hit multiple South African internet infrastructure providers using IP Fragmentation, Carpet Bombing, and DNS Application Layer techniques. Businesses not directly targeted still experienced website slowdowns, email outages, and failed payment gateway transactions because the attacks hit shared upstream infrastructure. Approximately 99% of South Africa's international internet traffic runs through a small number of undersea cable routes — attacks on ISPs propagate to sites hosted anywhere that uses those routes for international traffic.
If your site is behind Cloudflare or a similar WAF and suddenly returns 403 Forbidden errors, the WAF may have triggered a security rule — possibly a correct block of attack traffic, or a false positive. Log into your Cloudflare or security dashboard, check the Firewall Events log, and look for blocked IPs or triggered rules from the last hour.
If a legitimate IP is blocked (your own, your payment gateway, or a known crawler), whitelist it rather than disabling the WAF rule entirely. For a complete maintenance approach that includes security baseline checks, our website maintenance guide for SA businesses covers what to have in place before incidents happen.
Key Takeaway
If your site goes down during a known DDoS event affecting SA ISPs and your host's status page is clear, the problem is upstream. Contact your hosting provider and ask specifically whether their upstream transit providers are experiencing an attack. Separately: confirm your WAF is active and logging — a site with no WAF during a DDoS event has no defensive layer between the attack traffic and your server.
After the Outage: What to Do in the First Hour and What Prevents the Next One
Once your site is back up, the work is not finished. Website downtime is expensive whether or not you can put an exact rand figure on it — every minute your site is unreachable is a minute your competitors' sites are not. A recovered site with no post-incident record is a site waiting for the same outage to repeat.
Document what happened. Note the time the site went down, what error was visible, what check identified the cause, what the fix was, and how long recovery took. This record takes five minutes and is invaluable the next time the same symptom appears.
Set up free uptime monitoring immediately. UptimeRobot's free plan monitors up to 50 sites at five-minute intervals and sends email or SMS alerts when a site goes down. For an SA site with no monitoring in place, this is the single highest-leverage action you can take in the next 30 minutes. Our uptime monitoring guide for SA businesses covers the configuration in detail.
Confirm your backup is current. A restored backup from last week still loses seven days of orders, enquiries, and content. If you cannot answer "when was the last backup taken and where is it stored", your site's disaster recovery is incomplete. See our website backup best practices guide for what a current backup schedule looks like for a SA business site.
Review your hosting plan against your traffic profile. If a 502 or 503 brought you here, your current plan's resource limits may be the ceiling. A site generating enquiries and transactions deserves at minimum a managed WordPress hosting plan with autoscaling or a dedicated resource allocation — not the cheapest shared hosting tier your registrar offers. The full running cost breakdown for SA websites includes what to budget for hosting as your site grows.
Why South African Businesses Work With Growth Pulse Media on Website Health
Most website incidents are preventable. The businesses that call us after an outage almost always have the same gaps: no uptime monitoring, no staging environment, and no documented change log. Our web design and website management service builds in the architecture that prevents these incidents from becoming crises — managed hosting on generator-backed SA infrastructure, automated backups tested for restorability, SSL auto-renewal, and a maintenance schedule that separates plugin updates from content days so there is always a rollback point.
All work runs through senior-level oversight — not a junior team handling your site while the principals focus elsewhere. We run a deliberately limited client load because a website that goes down at 2pm on a Tuesday and takes four hours to recover is not a managed website; it is an unmanaged liability with a service agreement attached to it.
Who This Is NOT the Right Fit For
Not for you if: Your site is a personal project or informational brochure site with no transactions, no leads, and no revenue dependency. A free hosting tier that goes down occasionally costs you nothing measurable — a maintenance service would cost more than the downtime does.
Not for you if: You want to maintain full in-house control over every plugin update and deployment. Our maintenance model works because we make the calls — if you need to approve every individual change, the response time during an incident will be slower than what either of us wants.
Not for you if: You are still deciding whether to build a website at all. This guide assumes a live, revenue-generating site. If you are in the planning stage, start with understanding what a South African website costs to build and run before worrying about incident response.
Want Someone to Audit Your Site Before the Next Outage?
We check hosting architecture, DNS health, SSL renewal, monitoring coverage, and backup integrity — and tell you where the gaps are. No obligation.
Request a Free Site Health AuditFrequently Asked Questions
How do I check if my website is down for everyone or just me?
Open an incognito browser window and visit your site, then test on a different network (mobile data instead of Wi-Fi). If it still does not load, use a free global checker like UptimeRobot's website down tool or isitdownrightnow.com. These tools test your site from multiple locations and confirm within seconds whether it is a global outage or a local issue.
What does a 503 Service Unavailable error mean for my website?
A 503 error means the server is temporarily unable to handle the request — most commonly because the server is overloaded or under scheduled maintenance. It is one of the more recoverable errors because it signals a temporary state. Check your hosting provider's status page first; if no incident is listed, log into your hosting control panel and check CPU and memory usage. A traffic spike or a runaway plugin process are the most common causes on shared hosting plans.
How long does DNS propagation take when a website is down due to DNS changes?
DNS propagation — the time for all ISPs globally to recognise a nameserver or A record change — typically takes 24 to 48 hours, and can take up to 72 hours in edge cases. During propagation, some visitors may reach your site while others do not, depending on their ISP's DNS cache refresh interval. You cannot speed up propagation, but you can lower your DNS TTL (Time to Live) value before making changes to reduce future propagation windows.
Can load shedding cause my South African website to go down?
Load shedding is more likely to affect your visitors' ability to reach your site than the server itself. Reputable SA hosting providers run data centres with generator and UPS backup systems, so the server stays up. What drops is visitor connectivity — home routers lose power, mobile signals weaken, and browsing becomes intermittent. If a website down checker confirms your server is responding but your traffic is still flat, and load shedding is active, visitor connectivity is the probable cause.
What should I do immediately after my website comes back up?
Document the incident: time down, error visible, root cause found, fix applied, duration. Check that a current backup exists and confirm it can be restored. Set up free uptime monitoring via UptimeRobot if you do not already have it — the free plan monitors up to 50 sites at five-minute intervals. Without addressing the root cause, the same failure mode will recur.
Your Site Just Came Back Up — Now Make Sure It Stays That Way
We review your hosting architecture, backup schedule, monitoring setup, and update process and tell you exactly where the next outage is most likely to come from. Managed WordPress hosting on SA generator-backed infrastructure, automated backups tested for restorability, and a maintenance schedule that does not surprise you on a Friday. No obligation — we will get back to you within 24 hours.
Get a Free Website Health Review