Website uptime monitoring: what to check when a domain stops responding

Choose an endpoint and an expected result before interpreting a monitoring chart. A connection check, an HTTP request and a browser journey each test a different amount of the system.

A successful connection can establish that a service is reachable from the checking system. An HTTP check adds a response for a requested resource. A browser journey can test an application action if that journey is explicitly configured. Do not assume a domain monitor signs in, submits forms or validates payments.

For a business domain, begin with the public endpoint visitors use and record its intended destination. Keep separate tests for critical application workflows. A passed check then has an understandable scope.

Before an incident, record the usual result: hostname, protocol, final URL, response status and the timing metric you intend to compare. Keep the check interval, timeout and checking location alongside the configuration.

A useful observation should let another person answer these questions:

• What was requested, and when?
• Did DNS resolution and the connection complete?
• Was HTTPS validation successful?
• Which response or error was observed?
• Was a redirect followed, and where did it end?
• How does this result compare with recent checks under the same conditions?

If the monitor supports several checking locations, compare their results without treating them as a vote that automatically explains the fault. A difference deserves investigation into the affected path. If a location is unavailable, keep that coverage gap visible.

Select a check frequency and confirmation rule according to the consequence of a missed incident and the cost of noisy alerts. Document that choice.

HTTP responses give you a starting point for diagnosis. A 404 concerns the requested resource; a server error concerns the server's handling of that request. Record the actual status and response rather than reducing every unsuccessful request to the same label. MDN's HTTP status reference explains the distinctions.

For example, 503 Service Unavailable indicates that the server is not ready to handle the request. Maintenance and overload are possible causes, and a Retry-After header can provide a suggested waiting period. The status alone does not identify the underlying fault. See MDN's 503 reference.

Check planned maintenance, recent deployments and provider incident information before making changes. For your own infrastructure, match the observation time with relevant logs. Avoid restarting unrelated services simply because an alert arrived.

A slow response can matter even when the request succeeds. Time to first byte, or TTFB, measures the time until the first response byte begins arriving. Depending on the measurement, it includes stages such as redirects, DNS lookup, connection setup and TLS negotiation. web.dev explains TTFB and its measurement limits.

TTFB is not the time until the page becomes usable. Do not label an endpoint timing result as a complete page-speed score. Compare the same metric from the same conditions over a useful period, then investigate a sustained change.

For visitor experience, add browser performance tests or real-user measurements. Keep those results separately labelled so a fast server response does not conceal a slow interface.

In a hypothetical incident, a startup changes the hosting for example.org. The team can open the homepage from its office, but a later external check fails to connect.

Start by comparing the exact address and time. Then inspect the DNS answers and intended hosting destination, and review the connection and TLS results. Check whether the team and monitor reached the same endpoint before concluding that the monitor is wrong.

If the evidence points to an old or incorrect destination, repair the responsible configuration through its owner. If the network path remains uncertain, keep the incident open with the evidence attached. One successful local request should not erase an unresolved external failure; one external failure should not be described as a confirmed worldwide outage.

1. Preserve the first result. Save the timestamp, hostname, status or error and checking location.
2. Confirm the current state. Repeat a permitted check and review any configured confirmation results. Avoid adding rapid manual traffic to an already struggling service.
3. Find the failed step. Review name resolution, connection, certificate validation and the HTTP response in order.
4. Compare recent changes. Check DNS edits, hosting migrations, deployments and maintenance records.
5. Assign the repair. Give the relevant provider or teammate the observed evidence and the affected endpoint.
6. Verify recovery. Confirm a fresh successful observation, then test the affected customer workflow when it falls within your responsibility.
7. Record what remains uncertain. Keep coverage gaps and untested regions separate from confirmed recovery.

For the first diagnostic steps, use the guides to DNS record monitoring and SSL certificate monitoring. If the response succeeds but the content is unexpected, review website changes.

An uptime percentage needs a time window and a stated method. Ask whether a report measures successful samples or estimates available time, how it handles missing checks, and whether maintenance is included.

A failed sample establishes a failed observation then. Without additional evidence, it does not establish the exact moment the problem began or ended.

Track.Name puts uptime and performance observations in the wider domain timeline. Use that context to decide what to investigate, while keeping the monitoring system's coverage and the operator's recovery work distinct.