Defacement can pass uptime checks
Altered copy, links, or visuals can be served successfully with a 200 response and normal latency.
Production website integrity
Uptime checks can stay green while a homepage headline, payment instruction, canonical URL, or CTA is altered. OnChange watches the rendered result and gives incident responders a precise text, visual, and metadata diff they can verify quickly.
Integrity change detected
www.acme.com · HTTP 200 · checked 02:14 UTC
Primary CTA
HighThe main action changed outside the approved release window.
Destination URL
HighThe new CTA points to a different registrable domain.
Visual region
MediumThe current screenshot differs materially from the last known production state.
Integrity risk
A healthy response code only proves the server answered. Integrity monitoring asks whether customers received the page, message, and destination your team intended to publish.
Altered copy, links, or visuals can be served successfully with a 200 response and normal latency.
A changed payment address, download link, support number, or login destination may matter more than a full-page outage.
Commit correlation helps responders separate a planned release from a production change that has no obvious owner.
High-risk surfaces
Use several independent signals. A single text hash can miss a visual overlay; a screenshot alone can hide a changed destination or metadata field.
Detect changed customer messaging, payment details, support contacts, download instructions, and account actions.
Combine visible CTA copy with rendered and structural diffs to investigate unexpected changes in the actions customers are asked to take.
Compare browser-rendered screenshots to catch overlays, replaced assets, layout damage, and injected visible content.
Catch search-facing tampering or accidental head-tag changes even when the visible page body remains familiar.
Match detected changes against recent repository activity to identify likely planned releases and suspicious gaps.
Send material changes through Slack, Discord, email, or webhooks so the existing response workflow can take over.
Incident response procedure
OnChange does not remediate an incident. It shortens the time between an altered page and a responder having evidence precise enough to confirm and escalate.
Start with login, checkout, payment, downloads, contact details, and the highest-traffic public entry points.
Target meaningful page regions, remove routine noise, and keep both rendered and structured change signals active.
Use alert rules and commit context to raise the changes that fall outside normal release activity.
Confirm the diff, follow your rollback or incident plan, and share the restricted evidence record with responders or stakeholders.
Website integrity FAQ
Review how OnChange protects account data, credentials, and platform access.
Use recent Git activity to investigate whether a production change was expected.
Configure a production page monitor, selectors, intervals, and alerts.
Monitor the rendered content and destinations that carry the most brand, fraud, and customer-impact risk. Start free and route the first unexpected change into your response workflow.
Start with 5 free monitors