Content Change Monitoring

A Content Change Monitor fingerprints a page's visible text and detected technology stack on every check and compares that fingerprint against the last one on record — catching a page silently going blank, an unexpected redirect swapping in different content, or a technology migration (a new CMS, a new analytics tag, a CDN change) nothing else picks up on.

Availability

Available on every plan — a single HTTP request costs nothing like Synthetic or Screenshot Monitoring's browser overhead.

How it works

curl -X POST https://api.monsphere.com/api/v1/organizations/{orgId}/monitors \
  -H "X-Api-Key: msph_live_..." -H "Content-Type: application/json" \
  -d '{
    "name": "Homepage content",
    "type": "content-change",
    "target": "https://example.com",
    "intervalSeconds": 300,
    "timeoutSeconds": 30,
    "config": { "trackSourceCode": false }
  }'

Every check fetches the page and fingerprints two signals, always on:

• Visible text — the page's HTML with every <script>, <style>, and remaining tag stripped out, so markup-only changes don't count. This is a plain HTTP fetch, not a headless browser — it sees the server-rendered HTML, not whatever a client-side framework renders into the page after the fact.
• Technology stack — a small built-in signature set (WordPress, Shopify, React, Next.js, jQuery, Google Analytics, Cloudflare, and more) detected from response headers and page content, no external service call.

trackSourceCode (off by default) additionally hashes the raw HTML source. It's opt-in because most real sites embed something that changes on every single request — a CSRF token, a timestamp, a cache-busted asset URL — which would otherwise flag nearly every check as "changed."

This ships with a zero-config default alert — "Content Changed" — the moment any of these signals differs, no rule setup required, the same convention the built-in "Monitor Down" alert already uses. A monitor's very first check only ever establishes its baseline; nothing is flagged as "changed" until there's a previous fingerprint to differ from.

Third-Party Script Integrity

An optional add-on for Content Change monitors (plan feature Third-Party Script Integrity Monitoring). Turn on trackScriptIntegrity and every check also fetches each third-party <script src> the page loads and hashes it. If a script that was present on the previous check now has different content, the check reports it — third-party script integrity violation: https://cdn.example.com/widget.js changed — through the monitor's "Content Changed" alert. A compromised analytics tag, chat widget or CDN-hosted library is how card-skimming (Magecart-style) attacks usually reach a page; this is the early warning.

{ "type": "content-change", "target": "https://example.com/checkout", "config": { "trackScriptIntegrity": true, "scriptIntegrityExcludes": ["widgets.example.net"] } }

• Only scripts present on both checks are compared — a script added or removed is a content change, not an integrity violation.
• Well-known analytics and tag-manager domains whose files legitimately change on every request are skipped automatically.
• scriptIntegrityExcludes — optional: substrings (a full URL or a domain) for any other script that changes by design.
• It's opt-in because each check makes one extra request per third-party script.

How it runs

Like Cookie, WHOIS, and DNSBL monitors, a Content Change monitor doesn't go through Blackbox Exporter or Prometheus. It runs on MonSPHERE's own internal scheduler, the same one Heartbeat and Synthetic monitors use, so there's no region to pick.

Bot protection: if the site serves a bot-protection challenge (such as Cloudflare's "Just a moment...") instead of the page, the check says so and keeps your last real baseline — a challenge page differs on every request and would otherwise flag a change on every check. An ordinary error page (404, 500) is still fetched and compared: it appearing is a real change.