What Is Visual Website Monitoring?
Guide · visual monitoring
The check that judges your page the way a visitor's eye does, by comparing what the page actually looks like, not just whether the server answered.
Visual website monitoring is the practice of regularly capturing a screenshot of a live web page and comparing it, pixel by pixel, against a known-good baseline. When the new screenshot differs beyond a set threshold, you get an alert, so you catch problems a server-status check can never see.
A visual monitor loads your page in a real browser, the same way a visitor would, and saves a full screenshot. After you confirm the known-good state, that screenshot becomes the baseline. On each later scheduled visual check the monitor renders the page again, lines the two images up, and measures the percentage of pixels that changed. A small, expected change (a rotating testimonial, a live counter) stays under the threshold and is ignored. A large change (a hero image that vanished, a layout that collapsed, a page replaced with spam) crosses the threshold and can trigger an incident with both screenshots and the difference highlighted after applicable confirmation rules. Because the check is based on what the page actually looks like, it catches failures that are invisible to traditional uptime monitoring: the server keeps replying normally while real visitors stare at a broken or defaced page.
Uptime, content, and visual checks answer different questions
Uptime monitoring asks whether the configured request succeeded. Content monitoring fetches source HTML and compares visible text extracted from configured selectors. Visual monitoring is the one of these three that compares the rendered picture, by comparing the rendered picture. A site can pass uptime and content checks and still look broken, for example when a stylesheet fails to load: the words are all present in the code and the server responds, but the page renders as a wall of unstyled text. Visual monitoring can flag that on its next scheduled capture. Teams should combine the layers that match their risks without assuming any set catches every possible failure.
Failures that respond with a healthy server but a broken page
- Website defacement, hacked-in spam, and malicious redirects
- Broken or unstyled layouts after a deploy or plugin update
- Missing or broken images, logos, and hero sections
- Failed third-party scripts and widgets (chat, checkout, fonts)
- Error or certificate-warning pages shown to real visitors
- Blank or partially rendered pages
What it looks like in practice
On Room Service Resources (January 2026), a page-builder update finished successfully but failed to rebuild the cache, leaving the hero section as raw, unstyled content for every visitor while the server stayed healthy. Visual Sentinel detected a 48% visual difference on the next check and alerted the team, who fixed it in about ten minutes.
On Flex Town (February 2026), a similar update broke the homepage entirely (the hero image gone, the content collapsed) while the site was technically up. Visual Sentinel flagged an 84% pixel difference, alerted the team, and the team rolled the update back. Both incidents were completely invisible to uptime monitoring. See the full case studies.
Answers,
in plain English.
Can't find what you're looking for? Email support.
Catch the broken page
before your visitors do.
start watching in 60 secondsPermanent Free plan with 3 monitors. Paid plans start at $6/mo.