Why monitor from outside your infrastructure
Website monitoring means requesting your site from outside its own network on a fixed schedule so that you find out about an outage from an alert rather than from an angry customer. The value is in the vantage point: a check that runs inside your data center can pass while DNS, a load balancer, a CDN, or an expired certificate makes the site unreachable for everyone else.
External monitoring also needs nothing installed on your servers. The monitor behaves like a real visitor — it opens a connection, follows redirects, and reads the response — so it exercises the same path your users take.
What a website check should verify
A useful check verifies more than "the server answered". Start with the HTTP status code: a 200 is healthy, while a 5xx is a server error and a 4xx usually means the URL or authentication is wrong. Many outages return a 200 with a broken page, so add a content assertion — a string, CSS selector, or XPath expression that must be present — to catch a page that loads but is empty, shows an error, or has been defaced.
Measure response time as well. A page that takes eight seconds to load is failing its users even if it never returns an error, so a latency threshold turns "slow" into a signal you can act on. In PageLantern, HTTP checks combine the expected status code, optional content assertions, and a response-time budget, and each probe identifies itself with a User-Agent containing "PageLantern-Probe" so you can allowlist it in your logs and WAF (match the substring, not the whole header — the full string carries a version and a contact URL that can change).
How often should you check?
Check frequency is a trade-off between how quickly you detect an outage and how much traffic you send to your own site. A five-minute interval is fine for a marketing site; a checkout flow or an API that other businesses depend on deserves a much tighter interval. PageLantern runs checks as frequently as every 30 seconds on higher plans.
Shorter intervals detect faster but also surface more transient blips, which is why the interval should be chosen together with your alerting thresholds rather than in isolation.
Turn failures into alerts without the noise
A single failed request is not an outage — a dropped packet or a brief garbage-collection pause can fail one check and pass the next. Alert on consecutive failures instead. PageLantern opens an incident after two consecutive failed checks by default and resolves it on the first successful check (you can raise the recovery threshold too); both thresholds are per-monitor.
Route the alert to a channel your team actually watches — email, a chat webhook, or an on-call integration — and publish confirmed incidents to a status page so customers can self-serve the answer to "is it just me?". If you find yourself muting a monitor, that is a sign to tune its thresholds rather than ignore it.
A short setup checklist
Monitor the URL your users actually hit, including https and the correct hostname. Assert the status code and a piece of on-page content. Add a latency threshold. Set the interval to match how critical the page is. Require at least two consecutive failures before alerting, and send alerts somewhere they will be seen. Review noisy monitors monthly and adjust thresholds rather than disabling them.