Your client's live site broke at 3am. There was no build to fail.
Visual regression tooling was written for component libraries and pull requests. Most of the web does not work that way: a plugin auto-updates, a CDN drops a font, an editor deletes a block, a third-party script starts throwing. Side By Side watches the running site itself, on a schedule, and tells you what changed — by email, when the run finishes, so nobody has to remember to go and look.
A watchdog on the live site, not a gate in the pipeline.
SBS needs a URL, not a repository. Point it at production and staging, let it read the sitemap, pick the pages that matter, and capture a baseline. From then on every scheduled comparison answers one question: did anything visually change since the last time this looked right?
- No build, no commit, no CI job, no SDK in your test suite
- Works on WordPress, Drupal, Shopify, static, headless — anything that serves HTML
- Scheduled runs keep watching after the project ships and the team moves on
- Email when a run finishes, and again when it found differences — on every plan, so nobody has to remember to open the dashboard
- Console-error checks run alongside the pixel diff, catching the JavaScript failures a screenshot cannot show
- Shift-tolerant comparisonContent that simply moved down the page is detected as displacement and reported as a corrected diff — so a new banner does not flag forty pages as broken.
- Review, not archaeologySide-by-side, overlay and onion-skin modes; mark a result as a false positive or an intentional content change and it stops shouting at you.
What you get told, and when.
A watchdog that only writes to a dashboard is not watching anything. When a run reaches a terminal state — completed, partial or failed — Side By Side emails the members of that organisation who asked to hear about it. Exactly two messages exist, both on every plan, Free included.
Run finished
One email per run, the moment it stops: which site, which run, whether it completed, came back partial or failed, how many screenshots were compared and how many differences were found — and a link straight into the run. A failed run sends one message for the run, never one per broken URL; a run that recorded no results at all is not announced, because there is nothing to say.
Differences found
A second email, sent only when the run actually reported at least one difference, listing the largest ones by page and viewport with their diff percentage. A run that found nothing sends no alert, and a failed run never sends one at all — so the alert keeps meaning something.
Who gets it, and how to stop it
Every member of the organisation who has the matching switch on — both are on your Account page, both default to on, and every message carries a one-click unsubscribe that the platform actually obeys. Automation accounts are never mailed, and each person is sent a given message once per run even if the run is saved or re-imported again later.
Precisely this, and nothing more. Run-completion and difference alerts are the whole of what Side By Side sends about your runs. There are still no outgoing webhooks, no Slack integration and no usage-threshold emails at 80% or 100% of a limit — none of those are built on any plan, and the pricing page lists them as unbuilt. If you want a run's outcome inside another system, poll the REST API.
Tests the environments your CI cannot reach.
Staging behind a VPN. An IP-allowlisted UAT host. A client intranet portal. A pre-launch site on a private hostname with HTTP auth in front of it. A hosted CI runner cannot see any of them — which is exactly why nobody is testing them.
- Per-environment SOCKS5 proxy, configured once and reused across sites
- Per-environment override, including an explicit “no proxy” for the environments that do not need one
- Per-environment HTTP authentication for password-walled staging
- The same URL list, viewports and recorded actions across production, staging and dev
- Credentials are write-only in the interface and never returned in plaintext by the API
- productionhttps://clientsite.com — no proxy, no auth, scheduled weekly
- staginghttps://staging.internal.clientsite.com — SOCKS5 via the client VPN, HTTP basic auth
- uathttps://uat.clientsite.com — IP-allowlisted, reached through the same proxy, different credentials
- IsolationEvery site belongs to exactly one organisation. Screenshots are never public by default and cross-organisation access is refused server-side, not hidden in the UI.
- AI only on requestAn analysis happens only when one is asked for, and AI is a plan capability — on a plan without it the platform refuses to run one, so no image is sent. Any organisation admin can also switch AI off for the whole organisation under Configs → AI, on every plan including Free; while it is off every analysis is refused server-side.
Record the interaction in the browser, not in code.
The regression you actually need to catch is often behind a cookie banner, a mega-menu hover, an accordion, or a filtered listing state. Everywhere else that means writing and maintaining a Playwright script. Here it means opening the page, pressing record, and clicking.
- Chrome extension records clicks, hovers, scrolls, typing and waits as you perform them
- Hover states are detected properly — including CSS-only hovers that never fire an event
- The recording becomes a repeatable pre-screenshot action list attached to that URL
- An in-page drawer shows whether the page you are looking at is already tracked, and queues a job without leaving the site
- No selectors to maintain, no test framework, no engineer in the loop
The parts that make it a tool you keep using.
URL discovery
Crawl the site or parse the sitemap, then choose what to track. Duplicate paths are allowed — each tracked URL has its own stable id, so a page keeps its identity across runs.
Viewport presets
Define widths once, globally, and reference them by name from every site. Filter individual URLs down to the viewports that matter for them.
Single-screenshot retake
One page rendered mid-animation? Retake exactly that URL and viewport inside the existing run instead of running the whole site again.
AI diff triage
Each diff can be sent for analysis and comes back classified — real regression, intentional content change, or noise — with a written explanation. It is a plan capability with a monthly count, both enforced before the analysis is queued. Having every comparison analysed automatically is a Studio-and-above capability; on Starter you ask for the ones you want.
Job queue you can read
Baselines, comparisons, console checks, retakes, thumbnails and analyses all queue visibly, with status and history. One queue, first in first out — there is no priority lane, on any tier.
Organisations and roles
Owner, admin and member roles inside an organisation. Invite by email, seats capped by plan, and pending invitations counted against the cap so seats cannot be oversold.
REST API
Scoped API keys with per-key hourly rate limits, read from Studio and full read/write from Agency — both genuinely enforced. Outgoing webhooks and Slack notifications are not built; poll the API instead, or use the run and difference emails, which are.
Not built yet
So you find out here rather than after paying: outgoing webhooks, Slack notifications, shareable public run links, white-labelling them, run-report export to CSV or PDF, a priority queue lane, usage-threshold emails, purchasable add-ons, SSO and custom roles. (The run-finished and differences-found emails are built and ungated; what is missing is every other way of being told.) None of these exist in any plan today — the full list is on the pricing page.
Audit log & data export
Significant actions are written to an audit log on every plan — reading and exporting it in the app is the Agency capability, so upgrading unlocks the history rather than starting it. Every plan, including Free, can export its data and delete its account without asking us.
See it on your own site.
Fourteen days, no credit card, the API and AI analysis switched on so you can actually test them.