Website Down? A Troubleshooting Checklist

The alert says the website is down. Restarting something feels productive, especially when the button is large. Before pressing it, collect enough evidence to choose the right something.

This checklist follows the path of a web request: name resolution, network access, TLS, HTTP and the application response. Use it from the affected monitoring location. A successful request from your laptop is useful context, but it does not replay the failing request.

First, preserve the failed result

In RMON, open the check and record the failure time, agent, target and reported reason. Review the configured method, redirects, authentication, accepted status and body conditions. A check can fail because the application is unhealthy or because its configuration no longer describes the intended response.

Compare nearby history and other locations. A failure from one branch suggests a different starting point from simultaneous failures across independent networks. Neither pattern proves the root cause by itself.

Check freshness before interpreting the state. If measurements have stopped arriving, investigate the check’s enabled state, agent, assignments and result delivery. An old UP result is not a live health certificate; missing data is not evidence that the target is down either.

Can this location resolve the intended name?

Verify the hostname using the resolver relevant to the agent. Check for a missing answer, a timeout or a different answer from the one the application team expects. Internal and public DNS can intentionally return different addresses, so “different” needs context.

In RMON, a DNS check can query a selected resolver and record type. It reports resolution failures and timing. It does not compare returned values with an expected IP address or text; use a diagnostic lookup when you need to inspect the actual answer.

Check whether the HTTP check uses Resolve to IP. An explicit override changes the path being tested and may explain why the result differs from a normal DNS-based request. The DNS guide explains the available checks.

Can it establish the required connection?

Verify the target port, listener and firewall rules from the affected network. A timeout and a refused connection suggest different lines of investigation, but either still needs supporting evidence. A TCP check can test whether a connection can be established on the required port.

Ping tests ICMP reachability. Some networks intentionally block it while allowing HTTPS. Conversely, a successful Ping does not prove that port 443 is accepting requests. Choose the check for the question you are asking.

For agents running in containers, account for their DNS and network environment. A host-shell test and a request from the agent may use different routes or resolver settings. Use the network requirements to identify the actual connection source and destination.

Does TLS validate for the requested hostname?

If the connection fails during TLS, inspect the reported certificate error. Check the requested name, expiry, presented certificate chain and the CA trust configured for that connection. With client authentication, verify that the endpoint expects the credentials supplied by the HTTP check.

Target authentication is separate from mTLS used to deliver agent results. A fresh result reporting a target TLS failure and a failure to deliver any result are different situations.

After a certificate change, verify what the endpoint serves now, not only what the renewal command produced. Keep verification enabled while correcting the certificate or trust configuration. A quiet dashboard obtained by ignoring verification has not repaired HTTPS.

What response did the application actually return?

If the request reaches HTTP, compare the response with the check’s expectations:

• 401 or 403: inspect authentication, authorization and access controls along the request path.
• 404: confirm the hostname, path and routing after recent changes.
• 429: review rate limits, check frequency, retries and how many locations use the same credentials.
• 5xx: inspect the responding application or proxy and correlate its logs with the failure time.
• Unexpected 200: look for a login form, maintenance page or wrong JSON value that violates the body condition.

Review redirects and the final protocol. A redirect loop, an exhausted redirect limit or an HTTPS-policy failure may stop the request even when the first address responds. Do not widen accepted statuses until they include the error you meant to detect.

For slow responses, compare the timing stages in RMON: lookup, connection, TLS, redirects, waiting and download. They help locate where time is spent; they do not establish the underlying cause without application and network evidence.

Confirm recovery and improve the next response

After the fix, require fresh results from the affected locations and verify the recovery notification. Watch subsequent measurements for intermittent behavior rather than declaring victory after one lucky request.

Record the cause, the useful evidence and the first effective action in the check’s runbook. If the monitor missed the impact, add the missing condition or location. If its configuration was wrong, correct that expectation and explain why.

The results guide and RMON troubleshooting guide cover the next operational steps. A good investigation leaves both the service and the monitoring easier to understand.