Website uptime checks with useful context

Understand failures

Safe error categories distinguish DNS, timeout, connection, TLS, status and keyword failures.

Confirm before alerting

A second failed check confirms an incident by default, reducing noise from brief network glitches.

Choose the endpoint customers need

Start with a public URL that represents the service you want to observe. A homepage can be healthy while a customer portal fails. Set an acceptable HTTP status range and, where useful, require expected text or reject an error message. Authentication belongs in the supported API configuration rather than credentials embedded in a URL.

Investigate the failure category

For a DNS failure, inspect the hostname and published records. For TLS failure, review the certificate and hostname. For an unexpected status, compare application logs and recent deployments. A successful response with missing content needs a different investigation from a connection timeout; keep those expectations explicit.

Keep availability and performance distinct

Inspect response timing alongside check success, then use HTML timing monitoring for sustained degradation. It does not measure browser rendering or a complete checkout. Duration-based SLO reports show unknown coverage, maintenance and pause treatment separately from the dashboard's recorded-check uptime.

Make alerts actionable

Choose a working email or webhook channel and an incident owner. Bounded escalation can notify another channel if a confirmed outage continues. Upstream dependencies can suppress secondary notifications while retaining actual child checks. Planned maintenance should be declared rather than hidden by changing monitor expectations.

Common questions

Related guidance

• Inspect an HTTP response
• Run a website health check
• How monitoring works
• Investigate downtime
• Track HTML response timing
• Measure SLOs and error budgets