Netlify monitoring
The build passed. The preview looked fine. Is production OK?
Sitewatch checks the live Netlify site after every deploy — the redirects, the files each page loads, the content it returns — and alerts you when something the build could never have caught goes wrong.
- A deploy notification fires the check the moment the site publishes
- Catches redirect rules that only misbehave on the live domain
- Checks from EU and US to catch edge nodes serving an old deploy
Deploy notification received
Netlify → Sitewatch
8 pages checked
96 files verified
Redirect check
/pricing → sends visitors in circles
Email alert sent
team@company.com
01What can go wrong
Everything upstream was green.
Your tests passed. The build succeeded. The deploy preview looked right. None of those were looking at the live site, on the live domain, with the live redirect rules.
- 01A redirect rule you added last week starts conflicting with one the framework generates.
- 02The homepage is fine, so the build, the preview and your uptime check all stay green.
- 03But one important page now sends visitors in circles and never arrives.
- 04Nothing in your pipeline ever visits that page on the real domain.
- The first person to find out is a customer.
02Why traditional monitoring misses this
A build log describes the build. Not the site.
Neither your pipeline nor an uptime check ever opens a real page on the real domain. We don't just check that your site is online — we check that people can actually use it.
Build log + uptime check
Both true. Neither one visited the page that broke.
Sitewatch
Checked on the live domain, after the deploy is published.
03How far each check goes
Why your pipeline stops where it does.
Nothing here is a criticism of your build. Each rung costs more than the one above it, and a build system is deliberately built to stop early — which is exactly why the last two rungs need something else.
- 1
The build compiles
SecondsYour framework produces output without errors. Fast, cheap, and completely blind to anything that happens after publish.
- 2
Tests pass
MinutesYour suite runs against code, not against the deployed site on its real domain with its real redirect rules.
- 3
The preview looks right
One deployA preview runs on a preview URL. Domain-specific redirects, certificates and edge caching behave differently there.
- 4
The live site 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 loads
Many requestsOpen each page, follow its redirects, and fetch everything it asks for. This is many requests per page, on a schedule — 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 node or a half-published deploy is visible rather than assumed away.
Your pipeline stops at the third rung by design. Monitoring should start at the fifth.
04How Sitewatch catches it
One question, after every publish.
Not "did the build succeed?" — but the one your pipeline structurally cannot answer: does the live site work right now?
- ✓Every page still resolves
- ✓Redirects land where intended
- ✓Scripts and styling load
- ✓Images load
- ✓Content is what you shipped
- ✓Forms are still wired up
- ✓No preview builds in production
- ✓Certificate is valid
05Typical failures we catch
The breakage that only exists in production.
A redirect rule sends visitors in circles
Your rule and a framework-generated one disagree, on one route.
→That page is unreachable while the homepage looks perfect
A build plugin rewrote a file path
The page asks for one filename and the deploy shipped another.
→The page loads and nothing on it works
A function timed out and returned nothing
It answered within its limit, with an empty body.
→A whole section of the page renders blank
Some edge nodes serve the old deploy
Publishing finished, but not everywhere at once.
→Visitors in one region get a mismatched site
A split test is serving a broken branch
One variant has a build problem the other does not.
→A slice of your traffic sees a broken site and you see the average
Form handling quietly stopped working
A rebuild changed the form markup the platform relies on.
→Submissions vanish with no error anywhere
06Two-minute setup
Set up Netlify monitoring
- 01
Add your production URL
Sitewatch finds the pages and everything they load. No build plugin, no code changes, no effect on build times.
- 02
Add the deploy notification
In Netlify, go to Site settings → Deploy notifications and add an outgoing webhook pointing at your Sitewatch deploy hook.
- 03
Push and find out
Deploy your next change. The check runs against the live domain and alerts you if a redirect, a file or a form broke on the way.
07Who it's for
Built for teams who ship on merge.
08Different questions
Netlify Analytics vs Sitewatch
| Scenario | Netlify Analytics | Sitewatch |
|---|---|---|
| The question it answers | How much traffic came? | Does the site still work? |
| Missing or renamed files | Not detected | Detected, with the file named |
| Redirect loops | Not detected | Followed and flagged |
| Checks after a deploy | No | Automatic, via the deploy notification |
| Alerts outside the dashboard | No | Slack, email, webhook and more |
The question it answers
- Netlify Analytics:
- How much traffic came?
- Sitewatch:
- Does the site still work?
Missing or renamed files
- Netlify Analytics:
- Not detected
- Sitewatch:
- Detected, with the file named
Redirect loops
- Netlify Analytics:
- Not detected
- Sitewatch:
- Followed and flagged
Checks after a deploy
- Netlify Analytics:
- No
- Sitewatch:
- Automatic, via the deploy notification
Alerts outside the dashboard
- Netlify Analytics:
- No
- Sitewatch:
- Slack, email, webhook and more
2
Check regions on Pro (EU + US)
5 min
Fastest check interval
Free
For your first site
Deploy to Netlify with confidence
Add a deploy notification and verify your next publish in under two minutes. Free plan, no credit card.
09Questions
Netlify monitoring questions, answered
Yes, and it is the failure this page exists for. Sitewatch follows each page's redirects on the live domain during every check. A rule that sends visitors in circles, or hands them to a page that no longer exists, is flagged with the route named — even when the homepage is perfectly fine.
It checks what your visitors receive. If a function renders or serves page content, that output is verified — including the case where it times out and returns an empty body, which looks like a successful response to anything simpler. Sitewatch does not read invocation logs or execution metrics; it catches the user-facing result.
No. Sitewatch runs entirely outside your build — no plugin, no code changes, and no effect on build times. All it needs is a deploy notification webhook.
Any framework you deploy on Netlify — Nuxt, Astro, Gatsby, Hugo, Eleventy, Next.js, SvelteKit, Remix, or plain HTML. Sitewatch recognises the framework automatically and tailors its diagnosis to it.
Often, yes. Sitewatch checks from two regions on Pro and compares each page against its baseline, so a region still serving the previous publish shows up as content drift rather than passing silently.
The platforms overlap; the argument does not. This page is about the gap between a green pipeline and a working live site — build, tests and preview all pass without ever visiting production. The Vercel page is about verifying the output of a deploy itself. If you ship on both, read both.
10Related pages