Visual monitoring captures a page on a schedule and compares each capture against the previous one pixel by pixel. Verid runs that loop on any public URL, inside up to 20 regions you choose, with up to 20 elements hidden before the shutter fires. When more of the watched area moved than your threshold allows, the alert arrives carrying the change percentage and a red highlighted overlay of exactly which pixels moved.
It is visual regression testing aimed at what your visitors are loading right now, instead of at a build that already passed.
Spec sheet
Twelve answers with no adjectives in them, set out the way a lens carries its own data plate: the capture, the four things you control, and what you get back. Every number is read from the shipping product rather than from a marketing sheet, and the ones that differ by plan say so.
What runs, in what browser, at what size, how often.
The four settings that decide which pixels are even eligible to change.
What lands in the alert, what is kept, and what a plan includes.
The loop
Four things happen on every check, in this order, whether the monitor runs once a day or every five minutes. Three of them you configure once and never think about again. The fourth is the only one you ever hear about. Each stage below shows what it is handed and what it hands on.
takesa URL and a schedule
A visual monitor always loads the page in real Chrome, whatever fetch mode the text half of the monitor uses. One load produces every capture the check needs, at the viewport you set, either the full scroll height or the fold only.
viewport: 1440 x 900hands onone rendered page in Chrome
takesone rendered page in Chrome
Before the shutter fires, every ignore selector is hidden inside the page, so a cookie wall or a rotating testimonial cannot contribute a single pixel. Then each watched region is captured on its own, by CSS selector or by the rectangle you dragged.
ignoreSelectors: [".cookie-wall"]hands onone PNG per watched region
takesthis PNG and the previous one
Each capture is compared against the previous capture of the same region with a colour tolerance of 0.1 and anti-aliased edges excluded from the count. Captures of different sizes are padded from the top left rather than stretched, so content that pushed the page taller shows up as changed pixels where it actually landed.
changedPct: 2.41hands ona percentage and a red overlay
takesthe largest region percentage
A monitor with several regions reports the largest region percentage as its change. If that number reaches your threshold the alert goes out with the overlay attached. If it does not, the run is still recorded with its percentage and nothing is sent.
2.41 >= 2 so deliverhands onan alert, or a recorded quiet run
Two details in stage three are worth knowing before you trust the number. Captures of different sizes are padded onto a shared canvas from the top left rather than scaled, so added content reads as changed pixels where it landed instead of shifting the whole image. And a monitor with several regions reports the largest region percentage, not an average, so one small region changing completely is never diluted by three large ones that did not.
Scope
A pixel diff over an entire marketing page fires constantly, and that single fact is why most people who try screenshot monitoring turn it off in week two. The fix is not a cleverer comparison, it is a smaller one. Four settings decide which pixels are even eligible to change, and they are worth the five minutes it takes to get them right.
fullPage: true
The default. Every pixel of the full scroll height is in the comparison, which is right for a document you want intact and wrong for a long marketing page where the footer churns as often as the hero. It is also the setting that spends your screenshot budget fastest.
in the comparisonevery pixel of the full scroll height
regions: [ ... ]
A selector region is resolved again on every run, so it follows the element through a reflow. A rectangle region is fixed in full page pixels, so it survives a class rename. If a selector stops resolving, that region is skipped and the rest of the check carries on.
in the comparisonthe regions you named, and nothing between them
ignoreSelectors: [ ... ]
Masking is the strongest noise control on the page, because a hidden element contributes zero pixels rather than a small percentage you then have to tolerate. Cookie walls, carousels, live counters, ad slots and clocks belong here.
in the comparisonthe page minus every element you hid
viewport: { w, h }
Captures are taken at 1280 by 720 unless you override it, up to 3840 by 2160. Watching mobile and desktop is two monitors, which is also the only way to keep the two overlays readable instead of averaging them into one number.
in the comparisonthe fold only, at the size you set
Every panel's twenty cell meter is the share of a typical marketing page left eligible by that setting, drawn as a proportion rather than measured on your URL. The region picker in the dashboard renders the page once and lets you click an element or drag a rectangle, then writes the selectors and coordinates for you. The visual engine page walks through picking, masking and the three compare views in detail, and the playground opens a real pixelmatch output with no account.
Sensitivity
The threshold is the percentage of the watched area that has to change before the alert goes out. It is one number per monitor, anywhere from 0 to 100, and it is the difference between visual monitoring you keep and visual monitoring you mute. Verid defaults to 1 percent through the API and opens the dashboard form at 5 percent, with presets at 1, 5 and 10. Here is what each setting actually means on a real page.
0.5%Forensic. A moved button is a change.
Reserved for a checkout step, a signup form or a pricing table you have already masked properly. At this setting a single restyled input is enough, which is what you want on a page where a broken control costs money.
1%Strict. The API default.
The right starting point for a page you own and a region you scoped. A swapped hero image, a rewritten headline or a shifted block all clear 1 percent of a region comfortably, while font rendering differences between two Chrome runs do not.
2%Balanced. Layout moves, copy edits mostly do not.
A good default for a landing page above the fold once you have masked the obvious churn. It survives a badge rotating inside the hero and still catches the section that got added, removed or reordered.
5%Tolerant. The dashboard default.
What the visual monitor form opens on, and the right choice for a content heavy homepage or a page you do not control. A news strip or a testimonial carousel stays quiet, a redesign does not.
10%Structural only. The page genuinely moved.
For pages with animation you cannot mask, or a competitor running an A/B test on a module you have no selector for. At 10 percent you are asking about repositioning, not about edits.
| Page you are watching | Threshold | It catches | It stays quiet on |
|---|---|---|---|
| Checkout, signup, pricing table | 0.5 to 1% | A moved or restyled button, a changed plan label, a form field that stopped rendering | Font rasterisation differences between two Chrome runs |
| Landing page, above the fold | 1 to 2% | A swapped hero image, a rewritten headline, a section that shifted down the page | A trust badge or a review count rotating inside the hero |
| Content heavy homepage | 3 to 5% | A redesign, a band added or removed, a render that broke on one viewport | A news strip, a testimonial carousel, a live customer counter |
| Competitor page you do not control | 5 to 10% | A real repositioning: new hero, new pricing block, a new offer above the fold | Their A/B test rotating a module you have no selector to mask |
| Page with animation you cannot mask | 10% and above | Structural change only, where the layout itself is different | Everything under a tenth of the watched area, including most copy edits |
Percentages are hard to picture, which is why the first threshold most people choose is wrong. Each tile below is the same watched area divided into 160 sample cells, so one red cell is roughly 0.6 percent. Against a 2 percent threshold, only the second and third tiles would ever reach your inbox.
0.6%One control restyled
Quiet at a 2% threshold
2.5%A price and its button changed
Fires at a 2% threshold
11.3%A band was added and the page reflowed
Fires at every threshold below 11%
The order to do this in
Mask first, scope second, threshold last. Every element you hide with an ignore selector removes its pixels from the denominator entirely, so masking a cookie wall does more for your signal than any threshold you could pick afterwards. Scoping to a region does the same thing from the other direction. Only once both are right does the threshold become a judgement about how much change matters, rather than a way to absorb noise you could have removed.
The contract
Visual monitoring is a visual_config block on a monitor, not a separate resource, so the same POST that creates the monitor turns it on. The request on the left captures the pricing page above the fold at 1440 by 900 every hour, compares only the hero and the pricing table, hides the cookie wall and the testimonial carousel, and alerts when more than 2 percent of the watched pixels move. The payload on the right is what your endpoint receives when they do.
curl -X POST https://api.verid.dev/v1/monitors \
-H "Authorization: Bearer vrd_your_api_key" \
-H "Content-Type: application/json" \
-d '{
"name": "Pricing page visual guard",
"url": "https://yourapp.com/pricing",
"schedule_interval_seconds": 3600,
"fetch_mode": "browser",
"extract_config": { "method": "full_page" },
"diff_predicate": { "type": "field_changes", "field": "__visual_only__" },
"visual_config": {
"enabled": true,
"thresholdPct": 2,
"fullPage": false,
"viewport": { "width": 1440, "height": 900 },
"regions": [
{ "selector": "section.hero", "label": "Hero" },
{ "selector": "[data-testid=pricing-table]", "label": "Pricing table" }
],
"ignoreSelectors": [".cookie-wall", ".testimonial-carousel"]
},
"deliveries": [
{ "type": "webhook", "url": "https://api.yourapp.com/hooks/verid" }
]
}'{
"id": "del_8f2c1a94",
"version": "2026-05-01",
"monitor_id": "mon_3ab77c10",
"run_id": "run_51d0e2f8",
"fired_at": "2026-08-10T09:15:04.219Z",
"diff": {
"fields_changed": [],
"before": {},
"after": {}
},
"visual": {
"change_pct": 2.41,
"screenshot_url": "https://img.verid.dev/mon_3ab77c10/run_51d0e2f8/1.png?sig=...",
"diff_image_url": "https://img.verid.dev/mon_3ab77c10/run_51d0e2f8/1.diff.png?sig=..."
},
"monitor": {
"url": "https://yourapp.com/pricing",
"name": "Pricing page visual guard"
}
}Two fields in the request are there because the monitor schema requires them, not because a visual monitor uses them. A full_page extract_config and a predicate pointed at a field name that extraction never produces keep the text half of the monitor permanently silent, so the pixel threshold is the only thing that can deliver. The dashboard writes exactly that pair when you create a visual only monitor.
In the payload, diff is empty for the same reason and the change lives in the visual block: the percentage, a signed link to the capture and a signed link to the overlay, both valid for 7 days. The signature is an HMAC-SHA256 over the timestamp and the raw body, so a replayed or edited payload fails verification. Field reference in the visual monitoring docs.
Beyond the diff
Comparing two screenshots is an afternoon of work. Keeping fifty of them honest through redesigns, consent banners, A/B tests, a page that renders after hydration and a page that grew 400 pixels taller is the actual product.
Any tool can tell you two screenshots differ. The question that decides whether you still read the alerts in month three is how much has to move before you hear about it. In Verid that is one number per monitor, from 0 to 100 percent of the watched area, and it is evaluated against the largest of your regions rather than against the page. Sub-threshold movement is still measured and still recorded on the run, so a page can drift for a week and you can go back and see it without having been paged five times.
One number, evaluated against the largest region
thresholdPct 2, fires
Ignore selectors are hidden inside the page before any capture is taken, so a cookie wall contributes zero pixels rather than two percent you have to absorb. Filtering a diff afterwards can only ever guess which pixels were noise.
A selector region is resolved fresh on every run, so it follows the element down the page when something above it grows. A rectangle region is pinned in full page pixels, which is the better choice when class names are hashed at build time.
When a page grows or shrinks, the two captures are padded onto a common canvas from the top left instead of being scaled to match. Added content therefore shows up as changed pixels exactly where it landed, and the run records the dimension change in its own right.
Visual monitoring is a layer on a monitor, not a separate object. The same monitor watching your pricing page can hold a visual_config and an extract_config, so one alert stream tells you the layout moved and another tells you the price went from $49 to $42. Most tools make you pick.
Every stored pair opens as a drag slider, as side by side captures, or as the red overlay on its own, because the question changes: what moved, how much, and is that the thing you meant to ship.
Watchlist
Visual monitoring is a general instrument, which makes it hard to picture until you see a configured monitor. These nine are the shapes that recur most across accounts, written the way you would create them: the target, what the monitor is scoped to, and the threshold that decides when you hear about it. Six of the nine are pages the team running the monitor does not own.
CI signed off on the build, then a CMS edit, a CDN swap or a marketing tag moved the page anyway. A visual monitor on the fold is the only check that runs against what visitors are loading.
Spend keeps flowing while a broken form or a swapped offer quietly kills the page. Point one monitor at each live campaign URL and let the overlay show you the moment the creative stopped matching the ad.
Docs, pricing FAQ, legal and status pages get edited by people who never open your analytics. A daily full page capture turns a silent edit into a record with a picture attached.
The number is one job for field extraction. The layout is another: a fourth plan column, a moved enterprise tier or a new annual toggle is a strategy change that no selector was pointed at.
Repositioning shows up above the fold before it shows up in a press release. Watch the hero of the two or three companies you actually lose deals to, at a tolerant threshold so their A/B tests stay quiet.
Listing pages render at a stable URL, so a fixed rectangle over the result cards catches a new competitor entering the block, a badge appearing, or your own card sliding down.
This one is inverted: you are watching that something is still there. A consent banner that stopped rendering after a tag manager change is a compliance incident, and it is invisible to every text diff because the markup often still exists.
Partners rebuild your product page in their own CMS and it drifts. A capture per partner URL, compared weekly, gives the brand team evidence instead of a screenshot somebody took on a phone.
A failed webfont, a stylesheet that 404s, a third party widget that reflows the page: each one leaves the HTML valid and the page wrong. Pixels are the only sensor that reports this class of failure.
The pattern in that list is worth naming. A visual monitor earns its place wherever the thing you care about has no stable name in the markup: a layout, a rendering, a presence, a composition. Where the thing you care about does have a name, extract it as a field with the change detection API and put both on the same monitor.
Honest comparison
Four categories that all put two images side by side and answer different questions underneath. Read down the row that matters to you rather than across the column with the most ticks, because on two of these rows a different tool is the better answer and you should know that before you wire anything in.
| Criterion | Verid | Screenshot watchers | CI visual regression | Page archives |
|---|---|---|---|---|
| What it runs against | Live public URLs, on an interval you set per monitor | Live URLs, on a schedule | A build or a Storybook story, per commit | Whatever a crawler happened to fetch |
| What decides an alert | Percentage of watched pixels, anywhere from 0 to 100 | A visual change, sometimes with a relevance guess on top | Any pixel delta over a global tolerance | Nothing. There is no alert |
| Scope control | 20 regions plus 20 masked elements per monitor | Commonly one selected area per watch | Per story masks written in code | None |
| Pages you do not own | Yes, any public URL | Yes | No, only what your pipeline can build | Yes, if it was crawled |
| Structured fields on the same target | Yes, a field diff and a pixel diff on one monitor | Rarely. The image is the product | No | No |
| Blocks a release | No. It watches what is already live | No | Yes, that is the entire point | No |
| Evidence you receive | Change percentage, the capture and the red overlay, signed for 7 days | A diff image, usually with a summary line | A diff in the CI review interface | A snapshot you compare by eye |
| Integration surface | Signed webhook, email, REST API and a Node SDK | Email and chat, sometimes a webhook | Your CI provider | A public URL |
Tools in that class are page watchers first: paste a URL, pick an area, get an email. Keep that ease and add what a team needs in month two, which is 20 regions instead of one, a threshold you own as a number, a signed webhook your code can act on, and the same monitor also extracting named fields.
Keep them. They run inside your pipeline against a build and stop a bad commit, and Verid does none of that. Verid covers the half your pipeline cannot see: the CDN swap, the CMS edit, the expired asset and the third party script, on the URL after the deploy.
An archive answers what a page looked like when it happened to be crawled. There is no interval you control and no alert. A visual monitor on the same URL gives you your own capture on your own schedule, the overlay between consecutive captures, and a webhook when the change is big enough to matter.
Where it stops
Six places where Verid is the wrong tool, is weaker than the copy above would like, or stops on purpose. Two of them are behaviours you would otherwise discover on day three, which is the only reason to put a section like this on a page trying to sell you something.
Verid checks pages that are already live, on a clock. It does not build your branch, walk Storybook stories or fail a pull request. Keep Percy, Chromatic or BackstopJS in the pipeline and use visual monitoring for what production actually serves.
A visual change reaches a Slack or Discord channel as the monitor name, the URL and a run reference. The change percentage and the overlay ride in the webhook payload and in the email, so route a visual monitor to one of those two when you need the picture inside the alert itself.
An overlay proves the hero image changed. It cannot tell you whether marketing shipped it on purpose. Pair the visual layer with field extraction when you need the reason, or route the alert to whoever owns the page.
At 0 percent any non-identical pixel counts. The first check on a new monitor has nothing to compare against, so it is recorded as changed with 0 percent, and a threshold of 0 is the one setting that lets that baseline run deliver. Start at 1 or 5 and tighten from there.
If a page grows taller but the added area is effectively blank, the run records the dimension change while the changed pixel percentage stays near zero, which will not clear a 1 percent threshold. Watching for size alone is the one case where 0 is the correct threshold.
Each visual monitor renders at a single viewport in Chromium. There is no cross browser matrix and no Safari or Firefox capture. Watching mobile and desktop means two monitors, which is also how the two overlays stay readable.
The thirteen things teams ask before pointing a pixel diff at a production page, answered with the numbers the product enforces.
Visual monitoring captures a screenshot of a web page on a schedule and compares each capture against the previous one pixel by pixel. When more of the watched area changed than your threshold allows, it alerts you with the change percentage and a red highlighted overlay of exactly which pixels moved. It catches layout, imagery and rendering changes that a text or field level diff cannot see.
Visual regression testing runs inside your pipeline against a build and blocks a bad commit. Visual monitoring runs against the URL your visitors actually load, on a clock, and catches what a pipeline never sees: a CDN swap, a CMS edit, an expired asset, a third party script reflowing the page, or a competitor redesign. Most teams that ship weekly run one of each.
Yes. Add up to 20 regions per monitor. Each region is either a CSS selector, which is resolved again on every run so it follows the element through a reflow, or a fixed rectangle in full page pixels that you drag on the rendered page. The comparison runs only inside those regions, so a footer edit cannot trigger a hero alert.
Add them as ignore selectors, up to 20 per monitor. They are hidden inside the page before any capture is taken, so they contribute zero pixels rather than a percentage you have to tolerate. Then set the change threshold to match how lively the page is: 1 percent for a scoped region on a page you own, 5 percent for a content heavy homepage, 10 percent for a page you do not control.
Start at 1 percent for a region you scoped on a page you own, and 5 percent for a whole page or a page you do not control. The API default is 1 percent and the dashboard form opens on 5 percent with presets at 1, 5 and 10. Go to 0.5 percent only on a checkout or pricing page you have already masked properly, and above 10 percent only when the page carries animation you cannot mask.
For the job of watching a page and being told when it looks different, yes, and it will do it on any public URL including pages you do not own. The difference shows up once a team is involved: 20 regions and 20 masked elements per monitor instead of a single selected area, a threshold you set as a number from 0 to 100, an HMAC signed webhook rather than only an inbox, and the same monitor also extracting named fields so one target produces both a picture and a value.
Yes. Any public URL works, which is the usual reason teams point visual monitoring outward: competitor pricing pages, landing page tests and campaign creative. Use a more tolerant threshold there, commonly 5 to 10 percent, because you cannot mask the modules they rotate. Pair it with the competitor monitoring API when you also want their copy and prices as structured fields.
The change percentage for the monitor, which is the largest of its regions, plus a signed link to the current capture and a signed link to the red highlighted overlay. Both links stay valid for 7 days. The webhook payload carries them in a visual block alongside the monitor name and URL, and the email embeds the overlay directly.
The newest 10 checks per monitor keep their PNG captures and overlays, and older images are pruned from object storage automatically. The run records themselves, including each check change percentage, stay for your plan retention window: 14 days on Free, 90 days on Lite, 180 on Starter, 1 year on Pro and 2 years on Scale. Each plan also carries a monthly screenshot budget, from 200 MB on Free to 500 GB on Scale.
Anything that changes how the page looks without changing the value you named. A failed webfont, a stylesheet that stopped loading, an image swapped for one of the same dimensions, a button that moved below the fold, a consent banner that quietly stopped rendering, or a third party widget that reflowed a whole column. In each case the HTML is still valid and the extracted field is unchanged.
Yes, and it is the one part of Verid that never has a choice about it. A visual check always loads the page in real Chrome regardless of the fetch mode set for the text half of the monitor, so a client rendered page needs no extra configuration for the visual layer.
One check interval after it happened, plus render time. The interval is set per monitor in seconds and floored by your plan: once a day on Free, every 2 hours on Lite, hourly on Starter, every 15 minutes on Pro and every 5 minutes on Scale. There is no push from the page, so a page that matters in minutes needs Pro or Scale.
Yes. Visual monitoring is a visual_config object on the monitor, so the POST that creates the monitor can enable it, set the threshold, list regions and ignore selectors, and override the viewport. Nothing about it is dashboard only, and the region picker in the dashboard writes exactly the same object for you.