Screenshot monitoring in Tracker.ru is automatic captures of a page combined with pixel diff comparison. If the page's appearance changes beyond the configured threshold, you get a notification with a fresh screenshot and the changed regions highlighted. This catches a class of incidents that a regular HTTP check misses: the server returns 200 OK, but the user sees a blank screen, a Cloudflare anti-bot stub, a broken JS bundle, a tampered payment form or a defacement.
If your task is monitoring a site with screenshots, visual regression monitoring, or detecting layout changes between releases — this feature is at /features/screenshot-monitoring. Algorithm details are in /docs/features/screenshots, pricing — in /pricing.
What is screenshot monitoring and why does it matter?
Regular uptime monitoring checks the HTTP status code: a 200 OK means the site is formally working. In practice that's not enough. The server can answer with a correct status while a real user sees a completely different page: a blank screen after a JS bundle fails, the message «Payment form temporarily unavailable», a Cloudflare CAPTCHA wall, or broken layout because a font CDN went offline.
Screenshot monitoring closes this blind spot. It captures the page on a schedule and compares each new snapshot pixel-by-pixel with the previous one. If the appearance drifted beyond the configured threshold, you receive a notification with two images — «before» and «after». In English literature this class of tasks is called screenshot monitoring, visual regression monitoring or screenshot diff service — the same feature with different framing.
In Tracker.ru screenshot monitoring is built into the regular uptime product: no third-party service to wire up, no Playwright pipeline to maintain. Toggle it on the URL page; it runs alongside the HTTP checks and uses the same notification channels — Telegram, Email, MAX or webhook.
How does pixel diff detect visual changes?
Pixel diff in Tracker.ru runs a classic, predictable algorithm with no ML heuristics. Each pixel is compared on four RGBA channels with a tolerance of 10 units per channel — enough to filter out font antialiasing noise and PNG-compression micro-artifacts. Different pixels are clustered by connectivity, and clusters smaller than 100 pixels are dropped as noise (cursor blink, a one-pixel shadow shift, a flickering ad placeholder). The final delta percentage is rounded to 0.01% and compared against the per-URL threshold.
If the diff exceeds the threshold, the notification carries not only the number but the diff image itself: the snapshot with red highlights over changed regions. That solves the core job of a pixel-diff service — show in half a second what exactly changed, instead of forcing the engineer to compare «before/after» by hand. Step-by-step algorithm walkthrough — in /docs/features/screenshots.
Six real-world scenarios where screenshot monitoring saves the day
Screenshot monitoring closes incident classes that occur regularly in production — each one costs hours of downtime or lost conversion if you only learn about it from user complaints.
1. Visual regression after a deploy. A new build went out, CSS broke — paddings shift on the home page, the headline drops below the viewport, the buy button hides under the footer. The server still answers 200 OK and conversion analytics will show the dip only several hours later. Screenshot monitoring sees the divergence right after the next snapshot: a notification arrives with the diff image, the engineer rolls back in minutes.
2. Defacement or content tampering. An unexpected banner appears, a JS redirect to a foreign domain, a mining script injected. An HTTP check can't tell «our» home page from «not ours» — both return 200. Pixel diff records the visual change and flags the page, which matters for the security perimeter. Screenshot-based defacement monitoring is a common practice for landings, payment forms and customer cabinets.
3. Anti-bot stub or CAPTCHA instead of content. Cloudflare or an internal WAF flips into challenge mode. A real user sees «Checking your browser…» or a CAPTCHA, but the HTTP status formally remains 200. The screenshot makes it obvious immediately: instead of the familiar home page, a grey check screen.
4. Broken JS bundle and empty root. A JS error, a CDN drop with React, version conflict — <div id="app"> stays empty. HTML is delivered, JS hangs, the site is visually empty. The pixel diff between a working snapshot and an empty page is close to 100% — the alert fires immediately.
5. 404 assets and degraded layout. A deploy renamed the CSS bundle, the old path stayed in HTML, fonts disappeared. The site works but looks like a 1998 webpage. Typical case for layout-change detection — the HTTP check sees nothing, the screenshot sees it instantly.
6. Tampered payment form. Stripe / CloudPayments / another provider switched to «temporarily unavailable» mode and rendered a stub instead of card fields. Conversion to payment drops to zero, no one on the team knows why. Pixel diff sees that the visual block of the form changed and highlights the area.
The pattern across all six is the same: HTTP returns 200, log diagnostics are uninformative, only a real user can see the problem. Screenshot monitoring automates exactly that «how does the site look right now» check.
How does Tracker.ru compare to Checkly, BrowserStack, Uptime Kuma + Playwright?
There are several services on the market that work with screenshots, but their purposes and prices differ.
Checkly. A strong synthetic monitoring service. Visual regression / screenshot diff is a Team-plan feature priced from $64/month (the Starter tier at $24 doesn't include it; data current for 2026-05). USD-only billing, no Russian payment methods. A fit for teams already using Checkly for browser checks who'd rather not run a separate screenshot service.
BrowserStack. Built for manual and automated QA across browsers. Not an uptime tool: BrowserStack won't page an on-call engineer at 3 AM if the production layout broke. Useful for pre-release testing, not for continuous production monitoring.
Uptime Kuma + Playwright. A self-hosted combination: free under its license, but pixel diff isn't included out of the box — you have to assemble it yourself (scenarios, screenshot storage, comparison engine, notifications, Chromium infra, updates). A fit for teams ready to invest engineering hours into their own monitoring tooling.
Tracker.ru. Screenshot monitoring is built into the regular uptime product — not a separate service, not a separate subscription. Ruble billing, native Telegram bot, support in Russian. A fresh screenshot is automatically attached to the recovery notification — so the on-call engineer can see immediately how the page looks after the fix. Aimed at Russian and Eurasian teams that want fixed ruble pricing and a quick integration without building their own pipeline.
How much does it cost and what are the plan limits?
Screenshot monitoring is available on paid plans. The limit consists of two numbers: how many monitors can take screenshots simultaneously, and how many screenshots are taken per month.
| Plan | Monitors with screenshots | Screenshots per month | Price |
|---|---|---|---|
| Free | 0 | 0 | 0 ₽ |
| Basic | 2 | 10 | 290 ₽/mo |
| Pro | 10 | 50 | 790 ₽/mo |
Free doesn't include screenshots — it suits basic uptime monitoring. On Basic and Pro you can enable screenshots for the URLs you choose and pick a schedule: 1, 6, 12 or 24 hours (those are the four available presets; shorter intervals aren't supported — pixel diff is built for periodic control, not for instant per-frame reaction). On top of the schedule, when the site recovers from an incident, a fresh snapshot is automatically attached to the recovery notification — it counts against the plan's monthly quota.
More on plans and billing — at /pricing.
Frequently asked questions
How does visual monitoring differ from regular uptime monitoring?
An HTTP check looks at the server response code: 200 OK means it formally works. Screenshot monitoring looks at how the page renders for the user. 200 OK plus a blank screen, an anti-bot stub or a tampered payment form is an incident only pixel diff catches. Two different layers of control: HTTP answers «is the server delivering a page?», screenshot answers «does the page look the way it should?».
Can defacement be caught through screenshot monitoring?
Yes. Any visible change on the page — a banner, an unexpected JS injection, a logo swap, a JS redirect — lands in pixel diff and triggers a notification when the change exceeds the per-URL threshold. For landings and payment pages set a low threshold (1–5%); for dynamic home pages set it higher (10–20%) to avoid false positives on naturally changing blocks.
When exactly is a screenshot taken?
On schedule — 1, 6, 12 or 24 hours of choice (those are the four fixed presets; shorter intervals are not supported). Additionally, on site recovery after an incident, a fresh snapshot is automatically attached to the recovery notification so the on-call sees the page state after the fix. A screenshot is not taken when the site goes down — the trigger is recovery only, to avoid noisy snapshots during transient network instability.
Are screenshots taken from multiple regions?
No. Unlike HTTP checks that hit the URL from msk/eu/kz, screenshots are taken from a single dedicated location. One snapshot per URL per scheduled run, not one per region. This is intentional: pixel diff is computed between consecutive snapshots of the same URL over time, not between regions — so it surfaces temporal changes, not geo-rendering differences.
See also
- /features/heartbeat-monitoring — heartbeat monitoring for cron jobs
- /features/multi-region — multi-region monitoring (Moscow, Frankfurt, Almaty)
- /docs/features/screenshots — algorithm details and configuration
- /pricing — full plan and pricing comparison
- /compare/uptime-kuma — comparison with Uptime Kuma