For dev teams
CI passed. The deploy completed. Your pricing page just broke.
A green CI build means the code compiled — not that the live page still works for a real visitor. Sitewatch verifies production the moment your deploy lands — every page, and everything those pages ask for — and tells you in plain English what broke. No test scripts to write, and none to maintain six months from now.
- A deploy hook fires the check the instant your pipeline finishes
- Nothing to script — every file each page loads is discovered automatically
- Alerts say what broke and what a user would hit, not just which request failed
CI tests passed
All 142 green
Deploy to production
Completed
Sitewatch post-deploy check
Fetching what each page loads…
App bundle missing on /checkout
main.a3f9c2.js → 404
Free scan
Scan your production site right now — free
See what your test suite never catches.
02What can go wrong
Everything upstream was green.
Your suite runs against your code, in an environment you control. Production is a different machine, a different CDN, different routing rules and a third party you do not own.
- 01Tests pass, the deploy completes, and the dashboard turns green.
- 02The page still answers, so the uptime check stays green too.
- 03But the served page asks for a bundle that no longer exists, so nothing on it works.
- 04Nothing in your pipeline ever loaded that page from production.
- The first check against production is a user hitting it.
03Why traditional monitoring misses this
CI verifies your code. Uptime verifies your server. Neither verifies the page.
Both signals are real, and both stop short of the thing your users touch. We don't just check that the site is online — we check that people can actually use it.
CI + uptime check
Neither one loaded a production page and its dependencies.
Sitewatch
Against production, after the deploy is live.
04How far each check goes
Why CI stops where it does.
This is not a criticism of your pipeline. Each rung costs more than the one above it, and CI is deliberately designed to stay cheap and fast — which is exactly why the bottom rungs need something that runs after the deploy.
- 1
Unit tests pass
SecondsYour logic is correct in isolation. Runs in seconds and never touches infrastructure.
- 2
Integration tests pass
MinutesYour services agree with each other, in an environment you fully control.
- 3
The build and deploy succeed
One pipelineThe artefact was produced and shipped. Nothing has yet asked whether the result is usable.
- 4
Production answers
One requestAn uptime check confirms the server responds on the real domain. This is where ping-based monitoring stops.
Most uptime tools stop here
5Every page resolves and every file it needs is served
Many requestsOpen each page and fetch everything it references, from the real CDN, on a schedule. Dozens of requests per page — which is why cheap tools do not do it.
- 6
The content is what you shipped
A baseline per pageCompare each page against its baseline so a stale edge, a half-published deploy or an unintended content change is visible.
The two rungs your pipeline cannot afford are the two your users start at.
05How Sitewatch catches it
One question, after every deploy.
Not "did the pipeline pass?" — but the one production answers for you otherwise: is the deployed page usable right now?
- ✓Every monitored page resolves
- ✓Bundles are served
- ✓Styling is served
- ✓Fonts and images load
- ✓Third-party scripts load
- ✓Redirects resolve correctly
- ✓Content matches its baseline
- ✓Certificate is valid
06Typical failures we catch
The failure surface CI does not cover.
The CDN is not serving a file the page asks for
A path or hash changed and the served page still references the old one.
→The page loads and nothing on it works
A file comes back as the wrong kind of file
A host or cache layer serves an error page where a script should be.
→The browser refuses it silently and the feature disappears
A third-party script stopped being served
Auth, analytics or chat, from infrastructure you do not control.
→Their outage becomes your broken login
A routing rule creates a redirect loop
Platform-level rules collide in a way no test environment reproduces.
→One route is unreachable while the homepage looks perfect
One edge is serving a stale build
The deploy published, but not identically everywhere.
→A region gets a mismatched app and your dashboard averages it away
Content changed without anyone shipping it
A CMS edit, a cache purge, or something less pleasant.
→The page drifts from what you believe is deployed
07Fits your pipeline
Running in under five minutes
- 01
Add the deploy hook to your pipeline
Copy the Sitewatch webhook URL and add it as a deploy notification in Vercel, Netlify, GitHub Actions, CircleCI, or anything that can make an outbound request. Takes under a minute.
- 02
Your deploy fires it
The moment the deploy completes, the hook triggers a check against production. No polling, no waiting for the next scheduled interval.
- 03
Every page and everything it loads is verified
Sitewatch walks the pages you monitor, fetches every file they reference from the real CDN, and compares each page against its baseline.
- 04
A verdict lands in Slack
Within minutes: what passed, what failed, what changed since the last check, and a plain-English description of anything that broke.
08What happens the moment we find it
Detection is not the outcome. Rolling back is.
The alert is specific enough that the decision to revert takes seconds instead of a bisect.
We confirm it is real first
Every issue is re-checked before anyone is paged, so a single slow response mid-deploy does not wake the on-call engineer.
Diagnosed in plain English
What broke, which file, and what a user would experience — useful to whoever is on call, not just to whoever wrote it.
Ranked by what it costs
A broken checkout and a missing blog footer are not the same incident. Severity reflects the page, so a broken image on the blog never crowds out a broken checkout.
You can verify the rollback
Revert, run a check on demand, and close the incident on evidence rather than on the pipeline going green a second time.
09Who it's for
Built for teams shipping to production all week.
10vs. what you already run
Your CI went green. That does not mean production works.
| Scenario | CI/CD alone | CI/CD + Sitewatch |
|---|---|---|
| Files missing from the real CDN | Not checked — tests never touch production | Every file fetched from production after the deploy |
| A file served as the wrong kind of file | Silent — tests do not inspect what the host returns | Verified on every file, on every check |
| Third-party script outages | Not covered — usually stubbed out in tests | Checked in production alongside your own files |
| Test scripts to write and maintain | Yes — and they rot the moment the UI changes | None. Everything the page loads is discovered |
| Missing styling | Only if someone wrote a test for it | Automatic, on every check |
| Platform-level redirect loops | Rarely — hosting rules are not in your test env | Redirect chains followed and flagged |
| What the alert reads like | A stack trace, needing interpretation | What broke, where, and what a user would hit |
| Anything checks production after deploy | No — CI passes before the deploy and stops | Yes — the deploy hook triggers it |
Files missing from the real CDN
- CI/CD alone:
- Not checked — tests never touch production
- CI/CD + Sitewatch:
- Every file fetched from production after the deploy
A file served as the wrong kind of file
- CI/CD alone:
- Silent — tests do not inspect what the host returns
- CI/CD + Sitewatch:
- Verified on every file, on every check
Third-party script outages
- CI/CD alone:
- Not covered — usually stubbed out in tests
- CI/CD + Sitewatch:
- Checked in production alongside your own files
Test scripts to write and maintain
- CI/CD alone:
- Yes — and they rot the moment the UI changes
- CI/CD + Sitewatch:
- None. Everything the page loads is discovered
Missing styling
- CI/CD alone:
- Only if someone wrote a test for it
- CI/CD + Sitewatch:
- Automatic, on every check
Platform-level redirect loops
- CI/CD alone:
- Rarely — hosting rules are not in your test env
- CI/CD + Sitewatch:
- Redirect chains followed and flagged
What the alert reads like
- CI/CD alone:
- A stack trace, needing interpretation
- CI/CD + Sitewatch:
- What broke, where, and what a user would hit
Anything checks production after deploy
- CI/CD alone:
- No — CI passes before the deploy and stops
- CI/CD + Sitewatch:
- Yes — the deploy hook triggers it
Webhooks
Deploy hooks for any CI/CD platform
Minutes
From deploy to verdict
0 scripts
No browser tests to write or maintain
See what your last deploy actually did
Free plan monitors 1 site. Pro covers 100 sites at $19/month.
11Questions
Dev team questions, answered
Add the Sitewatch webhook URL as a deploy notification in your pipeline — Vercel, Netlify, GitHub Actions, CircleCI, or anything that can make an outbound request. When the deploy completes, the hook fires and Sitewatch immediately checks every monitored page on that site. The check runs against production, not against a CI environment, which is the entire point.
Yes. Sitewatch does not replace them and would be a poor substitute. Your tests verify your code; Sitewatch verifies that production works after the deploy — files served from the real CDN, headers your host actually returns, redirect rules that only exist in production, third-party dependencies that were stubbed out in your suite. Different failure surfaces entirely.
Everything that only exists after the artefact leaves your pipeline: a file the CDN is not serving, a script returned as an error page, a routing rule that loops, a third-party dependency that went down, an edge node still on the previous build, and content that changed without a deploy. None of these are reachable from a test environment.
It starts the moment the webhook fires and a full verdict typically lands within a few minutes, sooner on smaller sites. Critical failures are flagged as they are found rather than held until the whole check completes.
Yes, and with anything else that can send a webhook on deploy. Vercel and Netlify both support deploy notification URLs natively; GitHub Actions can call it with a single step at the end of the workflow. The endpoint is in your dashboard under site settings.
Sitewatch checks from two regions on Pro, so an edge serving a stale or broken build shows up as a region-specific failure rather than being averaged into a healthy-looking result. This is one of the hardest classes of problem to catch from CI, which runs in exactly one environment.
Browser tests can do things Sitewatch cannot — click through a flow, assert on state, drive a real browser. They also have to be written and kept alive as the UI changes, which is where most of them quietly die. Sitewatch requires nothing to maintain, so the coverage does not decay. Teams that need both usually keep a handful of critical browser tests and let Sitewatch cover the breadth.
12Explore more