Beamfar
Sign inStart free

Uptime monitoring vs security monitoring: what each sees

By the Beamfar team. Published . Updated . 4 min read.

Two different questions are easy to confuse. The first is “does the site answer?”. The second is “is what it answers still what we published?”. An uptime monitor answers the first. A security monitor, read from outside, tries to answer part of the second. A site can fail either one while passing the other, and clients care about both.

What uptime monitoring sees

An uptime check sends a request and judges the answer: did it arrive, how fast, with which status code, and optionally whether the body holds a piece of text you asked for. It also reads the certificate’s dates and the DNS answer. It is good at:

  • a server that is down or overloaded,
  • a certificate that expired or a domain that lapsed,
  • a DNS change that sends visitors somewhere else,
  • a page that answers with an error status, or without the text it should contain.

It is blind to anything that leaves the answer looking normal. A page that returns 200 and a normal layout while serving a hidden block of spam links is up. So is a page that loads one extra script from a host you have never heard of. What a 200 response hides goes through these cases.

What security monitoring from outside sees

A check run from outside reads what any visitor, or any crawler, can reach. That makes it good at changes in public output:

  • New or changed scripts. A script loaded from a host that was not there last week deserves a check. Adding a script to a page is one common way a site is compromised.
  • Hidden links and spam text added to pages, often visible only to search crawlers. The guide on SEO spam hacks on WordPress sites shows what they look like.
  • Redirects away, for example to a different site on certain visits.
  • Response headers that protect the browser, such as a Content Security Policy (MDN) or HSTS, appearing, changing or disappearing.
  • Files and paths that should not be public. Some checks request a short list of well-known paths.

These checks compare today’s page with a stored baseline, so the useful signal is a change, not a score.

What neither sees

Both kinds of monitor are limited by the same fact: they are outside.

  • Code and configuration on the server. A vulnerable library, a weak password or a misconfigured permission is invisible unless it shows in a public response.
  • Anything behind a login. A problem that only appears after signing in is not caught by an anonymous check.
  • Attacks that leave the public output alone, such as stolen data or a backdoor that only the attacker knows how to call.
  • Whether a version is actually vulnerable. A public version number is a hint. Distributions often backport fixes without changing the number, so a match with a known vulnerability means “possibly affected”, not “affected”.

The OWASP Top 10 lists the classes of weakness that matter most for web applications, and most need access to the code or the running application to find. An external monitor reports what is visible from outside; it is not a security audit.

A worked example

A small shop runs a popular CMS with a dozen plugins. On Tuesday an outdated plugin is abused and a script is added to the checkout page. The page still answers in 300 milliseconds with a 200 status and the right text. The uptime monitor stays green all week. A security read from outside sees on Wednesday morning that the checkout page loads a script from a host it has never loaded from before, and flags it. Someone opens the page source, finds the script, and removes it. The monitor never said the site was down, and it never should have: the site was up. The alert said that something had changed. The same week, a hosting fault takes the shop offline for four minutes at night; here the uptime monitor is the one that speaks. Each kind of monitor covers a failure the other cannot.

How to use both

  1. Run uptime checks on every site, with a text match for the part that matters. This is the base. It finds outages.
  2. Add a security read where a site changes without you. Sites that run a CMS with plugins, or that several people edit, change in ways nobody records. A scan that alerts on a new script host or a new hidden link catches changes that nobody planned.
  3. Treat a security alert as a reason to look, not a verdict. It says what changed and where. Whether the change is harmful is a human decision.
  4. Keep what monitoring cannot see in your routine. Updates, backups, access reviews and a review of who can publish are tasks, not alerts. The maintenance retainer checklist lists them.

What Beamfar does

Beamfar’s uptime checks run on every plan. The security checks, which read your pages from outside for signs of an attack, start with the Solo plan; see security checks for what they read and what they do not. They detect and alert. They do not block attacks, and a quiet result does not mean a site is safe: it means the checks found nothing that changed. You can run a free site check to see what an outside read of one page shows.

Sources

Read on . Standards and vendor pages change; confirm the current text before you rely on it.

Terms used in this guide

  • Uptime monitoringUptime monitoring requests a website from outside at intervals and alerts when it fails to answer. What it measures, what it misses and how it is confirmed.
  • HTTP status codeAn HTTP status code is the three-digit number that opens a server’s response: 2xx success, 3xx redirect, 4xx client error, 5xx server error.
  • HSTSHSTS is a response header telling browsers to use only HTTPS for a site. What max-age and includeSubDomains do, and why an expired certificate then hurts.
  • X-Robots-TagX-Robots-Tag is an HTTP header carrying robots directives such as noindex, for pages and files like PDFs, and easy to miss in the source.

Try it on your own sites.

Add your sites: checking starts as soon as you do.

Start freeSee every feature

No card for the Free plan.