Change monitoring
Detect website changes — and keep the evidence
Most damage to a website is not an outage; it is a quiet change. A plugin update that swapped your title tags, a redirect that appeared overnight, a script injected from a domain you have never heard of. MySentry records what your page looks like on every uptime check, reports what changed with a before/after view — and keeps a tamper-evident log, so a month later you can still show exactly what changed and when.
What is watched for changes
HTTP status & final URL
Redirect chain
Security headers
Title, meta description, canonical, robots
Third-party scripts
Visible text
Detected technologies
Built to stay quiet
Change detection tools usually die of noise: rotating banners, cache stamps and ad scripts produce a “change” on every visit, and after a week nobody reads the feed. MySentry is built the other way round:
- A change must be seen on two consecutive checks before it is recorded. A value that flips once and flips back never reaches the feed.
- Volatile response headers (dates, cache ids, request ids) and same-site bundler files are excluded at the source — they change on every deploy by design.
- Only external script hosts are tracked, with cache-busting query strings dropped, so the feed shows a genuinely new third party, not a version bump of your own bundle.
- A mass change — a redesign touching dozens of items at once — collapses into a single entry instead of flooding the feed.
Every entry carries its evidence
Each recorded change stores the before and after values, a SHA-256 hash of the observed state, the honest observation window (when the old value was last seen and the new one first seen), and raw evidence — response headers, the redirect chain, a fingerprint and excerpt of the page text — kept for 90 days. Feed entries are kept for a year.
Entries are linked into a per-site hash chain: every entry commits to the one before it, so history cannot be quietly rewritten or thinned out without breaking the chain — the same construction used in audit ledgers. When you need to show a client, a developer or an insurer what changed and when, you have a record rather than a recollection.
How it looks in the panel
The Changestab of each site shows the feed grouped by day: a one-line summary (“Response header strict-transport-security removed”, “External script added: cdn.example.com/x.js”, “Redirect chain changed”), expandable to the full before/after, the observation window and the integrity line of the entry. No alarms for the sake of alarms — the feed is a record you consult, and the alerting you already have fires for the things that break.
On WordPress: versions too
With the free MySentry Monitor plugin, change monitoring extends inside the site: core, plugin and theme versions, activations and switches — and for every available update, how many days it has been waiting. The plugin is read-only by design: it can report, and it cannot change anything.
Change monitoring questions
What does change monitoring actually record?
On every uptime check MySentry also records what the page looks like: the HTTP status and final URL, the full redirect chain, security-relevant response headers, the title, meta description, canonical and robots tags, the external scripts the page loads, the technologies detected, and a fingerprint of the visible text. When any of it changes, the site's Changes feed gets an entry with the before and after values and the time window in which the change happened.
Will change monitoring drown me in noise from dynamic pages?
No — that failure mode is designed out. A new state must be observed on two consecutive checks before anything is recorded, so rotating content that flips back never enters the feed. Volatile headers (dates, cache ids), same-site bundler files and cache-busting query strings are excluded at the source, and a mass change like a redesign collapses into a single entry. A site with nothing going on has an empty feed, not a busy one.
What evidence is kept for each change, and for how long?
Each entry stores the before/after values, a SHA-256 hash of the observed state and the raw evidence (response headers, redirect chain, a fingerprint and short excerpt of the page text) for 90 days; the feed entries themselves are kept for a year. Entries are linked into a per-site hash chain — every entry commits to the previous one — so the history is tamper-evident: it cannot be quietly edited or thinned without breaking the chain.
Does every change trigger an alert?
No. The Changes feed is a record you consult, not a siren: most changes are ones you made yourself. Alerts keep firing for the things that break — downtime, a missing expected phrase, errors, silent cron jobs. The feed is where you go when something looks off and you need to know what changed and when.
What does the WordPress version inventory show?
The plugin reports core, plugin and theme versions, activations and theme switches, PHP version and a few environment flags — once a day and after every update. The panel's WordPress tab lists every available update with how many days it has been waiting (amber from a week, red from a month). The plugin is read-only by design: it reports state and cannot install, update or change anything on your site.
My site sits behind an anti-bot firewall. Will I get false downtime alerts?
Sites behind aggressive anti-bot edges (a Cloudflare challenge, for example) sometimes answer 403 to monitoring requests while answering 200 to real people — the classic false alarm. When a would-be downtime alert carries that signature, MySentry first loads the page in a real browser; if it renders fine for humans, the alert is suppressed, and if it fails in the browser too, the alert goes out marked as browser-confirmed. A broken verifier never mutes a real outage: with no verdict within minutes, the alert is sent anyway.
Start keeping the record today
Free trial, no card required. Connect a site in two minutes.