The message "the site no longer works" can describe very different situations: slow page, DNS error, expired certificate, unavailable server or application error. The first objective is not to repair immediately, but to identify the affected layer.
1. Confirm the failure from another connection
Reload the page without using an old tab, then test from another browser. Then try another network, such as a mobile data connection. If the site works elsewhere, the problem may come from the cache, local DNS, proxy or network used.
Note the exact address, time and message displayed. A "domain not found" error, a certificate alert and an HTTP 500 response do not point to the same cause.
2. Check that the domain points to the right place
The DNS translates the site name into a network address. Check A and AAAA records, as well as any CNAME records. A recent change may not appear everywhere at the same time because of caching and the TTL.
- does the domain return the expected address;
- are the versions with and without
wwwconsistent; - does an old server or IPv6 address remain published;
- do the authoritative DNS servers respond correctly.
Avoid replacing DNS records until you identify an incorrect value. An unnecessary change may prolong the incident.
3. Check HTTPS and the TLS certificate
If the domain resolves but the browser displays an alert, check the certificate validity date, the names it covers and the certification chain. Also confirm that the server presents the correct certificate for the requested domain.
A redirect loop between HTTP and HTTPS, or between two domain names, can also render the site unusable while the server responds.
4. Test server availability
If DNS and TLS are correct, observe the HTTP code. A complete lack of response points to the network, firewall, reverse proxy or web service. A 502 or 504 response often indicates that the proxy cannot reach the application. A 500 response means that the application received the request but encountered an error.
On the server, check disk space, memory, service status and logs around the time of failure. Do not restart immediately: a restart can erase useful clues.
5. Examine the application and its dependencies
An unavailable database, an expired secret, incomplete migration or a slow third-party API can block the site. First test a local health endpoint when it exists, then dependencies one by one.
| Symptoms | Probable layer | First check |
|---|---|---|
| Domain not found | DNS | NS, A, AAAA and CNAME |
| Security alert | TLS | Certificate validity and domain name |
| 502 or 504 | Proxy or application | Upstream service and timeouts |
| 500 | Application | Application logs |
| Slow | Resources or dependency | Response time per component |
Get an initial public diagnosis
DomainCheck checks public domain information, including DNS, HTTPS, TLS and messaging. This control helps to quickly rule out several causes without intervening on the server.
Analyze my domain6. Document before closing the incident
After recovery, keep the chronology, cause, correction and signals that would have detected the problem earlier. Then add a useful check: TLS expiry, DNS changes, a health endpoint or an availability alert.
To automate these controls, see also the guide Monitor a domain, its TLS certificate and DMARC.
Published on 5 August 2026.