Why monitor your site from outside?

An active process, a healthy container or a page accessible from the server does not prove that the site works for its visitors. Between the domain and the public page are the DNS, the network, the TLS certificate and the web server. External monitoring tests this chain from another perspective.

Why Local Control Can Miss a Failure

A control performed in the same environment as the site may bypass part of the public path. It can use a different DNS cache, directly join an internal service or ignore a routing defect. The dashboard then remains green while some visitors encounter a mistake.

External control raises a more useful question: Does the site actually respond from an independent network?

What external monitoring provides

• detect visible unavailability from the Internet;
• control domain resolution and HTTPS connection;
• measuring HTTP status and external latency;
• distinguishing a site failure from a measurement point problem;
• confirm an incident before sending an alert;
• maintain a history to track availability and recovery.

How control works

The user has nothing to install. When a domain is monitored, an independent measuring point periodically tries to reach its public address in HTTPS. It validates the requested name, TLS certificate, HTTP status and response time, and then transmits a standardized result to InfraCheck.

Control does not track redirects and does not download the full content of the page. Its objective is to quickly check public availability without browsing the site.

Why confirm a breakdown before alerting

Only one error can be caused by a very brief cut. To limit false alerts, the first failure places the domain on hold. A second consecutive real failure confirms the incident. The following controls remain silent until the site returns.

When the site becomes available again, the condition returns to normal and a recovery notification can be sent. A measurement point failure is not interpreted as a site failure and does not resolve an ongoing incident.

What the user sees in InfraCheck

In an audit, the line External availability Sentinel indicates the HTTP status, latency and control point.

Disponibilité externe Sentinel
HTTP 200 · 184 ms · point externe

In Protect, the user finds the availability calculated over the last 24 hours, the average latency of the successful controls and recent measurements. Measurement point errors remain visible, but do not artificially degrade site availability.

What about external DNS verification?

During an audit InfraCheck, a DNS resolution can also be executed from an independent point. It compares the public IPv4 and IPv6 addresses observed elsewhere with those in the main report. This cross-check may reveal an incomplete propagation, an old address still visible or a private response published by mistake.

This DNS measure remains ad hoc: it complements the audit, but does not in itself constitute continuous or multi-regional DNS supervision.

When this monitoring is particularly useful

• After deployment: confirm that the new version responds from the Internet.
• After a DNS modification: Identify an address still visible on another network.
• For intermittent failure: consult history and recent latency.
• For IPv6: detect a site that can be reached in IPv4 but fails on another address family.
• For alerts: be notified after the incident has been confirmed and then upon recovery.

The limits to be known

An external point brings an independent look, not a global vision. It does not replace measures spread across several regions, complete application supervision or a real navigation scenario. However, it is a simple and concrete verification of the public accessibility of the site.

Published on August 6, 2026. Updated for users dInfraCheck and Protect.