Host and network
Origin down, overload, provider incidents, regional path failures. Multi-region uptime surfaces geography disagreements.
Downtime · Faster detection
Website downtime causes and faster detection.
Website downtime is any period customers cannot use what they came for: hard outages, DNS black holes, certificate blocks, or “up” pages that are broken. Faster detection means named alerts from multiple regions before the inbox fills with screenshots.
By Muhammad Hamza, Founder of AeptoPublished Updated
Common causes, grouped by layer
Blame the right layer so the fix matches the alert.
Operators waste time when every red badge looks the same. Separating host failures from DNS, SSL, and application content failures shortens mean time to understanding, even before mean time to repair.
DNS control
Bad deploys of records, expired NS hygiene, or hostile changes. Pair uptime with Theft Guard baselines.
Trust layer
Expired or mismatched certificates block users even when the server answers. Monitor SSL windows continuously.
Paid
Application body
Deploys and CMS failures that still return 200. Content Monitoring names those for revenue URLs.
Slow as down
Timeouts and glacial responses feel like downtime. Slow-response baselines catch cliffs before hard failure.
Domain expiry
Not classic “server down,” but the site disappears from the usable internet when the name lapses.
Detection habits that actually shrink time-to-know
Tools help. Routing and naming help more.
-
Probe what customers hit
Homepage-only checks miss checkout and login. Pick URLs that represent revenue.
-
Use more than one region
Single-probe calm is a false friend for distributed audiences.
-
Name the domain in the alert
Portfolio owners cannot decode anonymous red tiles at 2 a.m.
-
Separate private triage from public status
Operators work Attention. Clients get a status page URL.
From causes to the Aepto queue
Uptime checks catch outages. Content Monitoring catches pages that return 200 but are broken.
Aepto is not full APM. It is portfolio detection across uptime, SSL, DNS, renewals, and optional content checks.
Which layer failed, and what should you check first?
The alert type tells you which door to open. Starting at the wrong layer costs the most time.
| Signal in Attention | Likely layer | First check |
|---|---|---|
| Down in every region | Host, server or app | Hosting status, server logs, the last deploy |
| Down in one region only | Network or CDN edge | CDN status and that region's history |
| SSL error | Certificate or TLS setup | Expiry date, and which system issues the certificate |
| DNS drift | DNS or registrar control | Who changed which record. Revert if nobody planned it |
| Content incident with HTTP 200 | Application, database or CMS | Database connection and the last plugin or code update |
| Slow response | Hosting contention or a heavy page | Time to first byte against the site's baseline |
| Renewal due or expired | Registrar billing | Payment method and auto-renew |
What is the triage order when something goes red?
Fast detection still needs a fast decision.
- 01
Read the label
Uptime, SSL, DNS, content or renewal. It stops the "restart the server while DNS is wrong" loop.
- 02
Confirm from a second region
Multi-region history usually shows whether the failure is local.
- 03
Communicate
If clients are affected, share the status page before the long technical thread.
- 04
Fix, then close the gap
Repair the broken layer, then add the monitor or URL that would have caught it sooner.
Why does detection speed matter so much?
Small percentages hide long outages.
10×
each extra "nine" of availability is an order-of-magnitude improvement toward 100%
Source: Google SRE book
~44 min
of downtime a month still meets a 99.9% uptime target
TTL
how long resolvers may cache a record before asking again, which is why bad changes spread gradually
Source: RFC 1035
Common questions
What are the most common downtime causes?
Hosting and network failures, DNS misconfiguration or hijack, SSL problems, bad deploys, overloaded origins, and application errors that may still return HTTP 200.
How do you detect downtime faster?
Multi-region probes, named alerts, short check intervals appropriate to plan, and content checks when availability alone has lied. Route alerts to people who can act.
Can DNS cause downtime without the server dying?
Yes. Wrong records or NS changes can make the site unreachable or point traffic elsewhere while the old host is healthy.
Where does Aepto fit?
Uptime, slow response, SSL, Theft Guard, and paid Content Monitoring feed Requires Your Attention so detection is portfolio-wide, not one site at a time.
Do status pages detect downtime?
Status pages communicate. Detection comes from monitors. Pages should ride the same checks you already trust.
How do I tell origin failure from a regional issue?
If every region fails, suspect origin or DNS. If one region fails, suspect pathing or a local provider. Multi-region checks make that split visible.
What if uptime is green but users complain?
Suspect application/content failures. Add paid Content Monitoring so body-level errors enter the same Attention queue.
Know the layer. Then fix the layer.
Start free. Put downtime next to SSL and DNS in Attention.