Your website works. Your uptime monitor says it doesn’t. Who’s right?

Two different answers

During a connectivity investigation, a direct command-line HTTPS request reached the website but received a 403 response. A repeat request using a browser-style user agent returned 200.

That was not a test of a particular uptime-monitoring product. It was a useful demonstration of why an automated check and a person opening a website can report different experiences.

Start by defining “down”

A monitoring result might mean that a connection timed out, a certificate check failed, an unexpected status was returned or some expected content was missing. Those are different observations, and they point to different investigations.

In this case, the first request had already completed its connection and TLS negotiation. The 403 was a response from the site’s protection layer. Treating it as proof that the network port was blocked would have sent the investigation in the wrong direction.

What we established

We compared the responses and the available firewall evidence. The application firewall had classified the command-line user agent as suspicious. Changing that request characteristic produced a successful response.

That established why the specific request was refused. It did not establish that every visitor could reach the site, or resolve the separate question of intermittent availability. One successful check is evidence about that request, not a universal health certificate.

Make the check specific

For a real monitoring alert, capture the time, URL, method, response and check location. Compare the same request conditions before changing one variable at a time. Relevant server and firewall logs can help show which layer answered.

• Did the request reach the server at all?
• Was it rejected, redirected or challenged?
• Did it receive the expected page?
• Does the result change with the check’s request characteristics?

A browser test can add useful context, but it should not replace investigating the failed check.

Fix the interpretation before widening access

If a legitimate monitor is being refused, first confirm its behaviour and what it needs to check. Then consider the narrowest appropriate configuration change and verify it.

A broad exemption can hide the symptom while creating a different problem. Equally, making a monitor look more like a browser may be appropriate for one check but tell you less about a separate visitor journey. The monitoring purpose should drive the configuration.

The lesson

Both reports can describe something real. The website may be serving normal requests while refusing the monitor’s request.

The valuable next step is to identify the difference. That gives you a meaningful alert and a targeted fix, rather than a server change made on the strength of an ambiguous “down” message.