Incident triage · Practical free guide
Website down? Separate DNS, TLS certificate, and HTTPS response issues
A website failure can originate from DNS, certificates, reverse proxies, or the application itself. Checking the layers in order is usually more informative than blindly restarting services or changing settings.
1. Check public DNS resolution
When a browser cannot resolve a hostname, verify that the expected public A/AAAA records exist. Inspect spelling and recent DNS changes. A successful lookup does not prove the website works; one failure alone does not prove the registrar or ISP is at fault.
2. Check the TLS certificate
For certificate warnings, review expiry, hostname matching and whether the TLS handshake succeeds. A healthy certificate does not mean the origin application is healthy or that every client can connect.
3. Check the HTTPS response
Even when DNS and TLS work, HTTPS can return 4xx/5xx errors or time out. A 502 often suggests a gateway-to-upstream problem, but the cause still requires appropriate proxy, service and log evidence; an external probe cannot identify the internal root cause.
What should you do with the first report?
- Record the hostname, timestamp, DNS outcome, certificate details and HTTP status.
- Compare the timeline with changes to DNS, certificate renewal, reverse proxy settings and deployments.
- Do not modify production without access authorization, backups and a rollback plan.
- If you need deeper assistance, submit a redacted description of the symptoms and desired outcome; confirm scope and pricing before any work.
Check your website now
No login required. Enter a public domain you are authorized to inspect to see DNS, TLS and HTTPS evidence. Request further service only if you choose; no payment or server change occurs automatically.
Run a free check →This is general troubleshooting information, not authorization to test third-party targets. Zoryvia Home