DNS, TLS and HTTP are often grouped under “uptime”, but their success conditions differ. A DNS answer does not prove a secure connection. A valid certificate does not prove the application works. An HTTP success response does not prove the content or user journey is correct.
DNS checks: can the name reach the intended service?
DNS maps a hostname to the records used by clients and other systems. A monitoring check can verify that a record exists, returns an expected value or remains consistent across authoritative and recursive resolvers. The exact check should match the risk: absence, unexpected destination, delegation failure or slow propagation are different conditions.
Monitor the records that matter to the service. Website checks normally focus on apex and www records. Email DNS such as MX, SPF, DKIM and DMARC is operationally important but should be managed as a separate scope so a web change cannot silently disturb mail.
TLS certificate checks: can the visitor establish trust?
A certificate check should cover the hostname presented to visitors, the validity period and the trust chain. Expiry warnings need enough lead time for investigation before a renewal problem becomes a public outage. Automated renewal reduces routine work, but the result still needs external verification.
On a new hosting mapping, wait until the certificate presented by the intended origin covers both the canonical hostname and any supported alternate hostname. A hosting-panel message is not the same as a browser-valid certificate.
Certificate monitoring does not replace secure TLS configuration. It is one control that detects a narrow class of problems.
HTTP checks: what did the endpoint return?
HTTP response status codes are grouped into informational, successful, redirection, client-error and server-error classes. The acceptable result depends on the endpoint. A public page may require a direct 200. A canonical HTTP hostname may correctly redirect to HTTPS. An authenticated endpoint may return a deliberate access-control response.
Add an expected content marker when a successful response can contain a generic error shell or hosting placeholder. Use a stable marker controlled by the site, not a marketing sentence that changes during normal editing.
| Check | Good question | Misleading shortcut |
|---|---|---|
| DNS | Does the authoritative answer match the approved destination? | Any answer means the site is healthy. |
| TLS | Is the certificate valid for this hostname with useful renewal lead time? | HTTPS once worked, so renewal is guaranteed. |
| HTTP status | Does this route return the explicitly allowed status? | Every status below 500 is fine. |
| Content | Does the response contain a controlled success marker? | A 200 response proves the application is correct. |
Combine checks without creating duplicates
Use a small diagnostic stack: DNS resolution, certificate validity, HTTP response and one meaningful content or journey check. When an event occurs, the pattern of failures narrows triage. If DNS fails, later layers may be unreachable. If TLS fails while DNS is correct, investigate the certificate and virtual-host mapping. If the lower layers pass but a journey fails, focus on application behaviour.
A first-response sequence
- Confirm scope: one probe, one region, one hostname or many?
- Check authoritative DNS separately from cached recursive answers.
- Inspect the certificate actually presented using the intended hostname.
- Record the HTTP status, redirect chain and response marker.
- Run the smallest safe application or journey check.
- Communicate only the confirmed impact and next review time.