Deploy & release monitoring
Catch Broken Deployments Before Your Users Do
You shipped at 5 PM. The deploy looked clean. CI passed. But a CDN cache bust failed, a bundle reference changed, and now your pricing page has no styles and your signup form does not submit. Sitewatch checks your pages and every referenced asset -- so broken deploys get caught in the next check cycle, not by your customers.
- SHA-256 HTML fingerprinting detects unexpected structural changes
- Redirect loop and host drift detection on every check
- 2-of-3 retry confirmation filters transient deploy-window noise
Post-deploy regression detected
Confirmed via retry
Affected assets
Recent activity
- ASSET_MISSING: /js/app.3f8a1c.js returned 4046:00 AM
- ASSET_MIME_MISMATCH: style.css served as text/html6:00 AM
- HTML fingerprint changed on /pricing6:00 AM
- All assets OK on /about (no regression)6:00 AM
Why it matters
Every deploy is a chance to break something. Know when it happens.
Missing asset detection
A deploy changes bundle filenames but the HTML still references the old ones. Sitewatch checks every script, stylesheet, and image -- a 404 or 410 on any of them triggers an incident.
MIME type verification
CDN misconfigurations after a deploy can serve JavaScript as text/html or CSS as application/octet-stream. Browsers silently reject them. Sitewatch catches the mismatch.
HTML fingerprinting
SHA-256 fingerprints of your page HTML detect unexpected structural changes. Know when a deploy alters page output you did not intend to change.
Redirect regression detection
Routing changes in a deploy can create redirect loops or send users to the wrong host. Sitewatch flags REDIRECT_LOOP and HOST_DRIFT incidents automatically.
Noise-free confirmations
2-of-3 retry confirmation means transient errors during a rolling deploy window do not create incidents. Only persistent failures trigger alerts.
Six alert channels
Get notified via Slack, email, SMS, webhook, PagerDuty, or Opsgenie. Each alert includes the failure type, affected URL, and HTTP status code for fast triage.
Automatic performance baselines
Sitewatch calculates response time baselines automatically from your site's history. Regressions are detected without manual threshold configuration — if your site slows down beyond its normal range, you'll know.
6
Incident types detected
2-of-3
Retry confirmation
5–30 min
Check intervals
Detection coverage
What gets caught after a deploy
Asset failures
- ASSET_MISSING -- JS, CSS, or image returns 404 or 410 after deploy
- ASSET_MIME_MISMATCH -- asset served with wrong Content-Type header
- UNAVAILABLE -- page or asset returns 5xx or network error
Page-level regressions
- REDIRECT_LOOP -- routing change creates infinite redirect cycle
- HOST_DRIFT -- page unexpectedly resolves to a different host
- NON_HTML_PAGE -- expected HTML page returns non-HTML content
- HTML fingerprint change -- SHA-256 hash differs from previous check
Simple and reliable
How deploy monitoring works
Fetch and parse
Sitewatch fetches your page over HTTP and parses the HTML to extract every script, stylesheet, and image reference.
Check and fingerprint
Each asset gets a HEAD request to check its HTTP status and MIME type. The page HTML is fingerprinted with SHA-256 to detect structural changes.
Confirm with retries
Any detected failure is retried using 2-of-3 confirmation. Only persistent issues create an incident -- no noise from transient deploy windows.
Alert your team
Confirmed incidents trigger alerts across your configured channels — Slack, email, SMS, webhook, PagerDuty, or Opsgenie. Each includes the failure type, affected URL, and HTTP status for fast triage.
Your CI passed. But does your site actually work?
Free plan. No credit card. 2-minute setup.
The post-deploy gap
CI says green. Your visitors see a broken page.
| Feature | Uptime tools | Sitewatch |
|---|---|---|
| Asset verification | Not checked | Every JS, CSS, and image verified |
| MIME type checks | Ignored | Content-Type validated per asset |
| HTML change detection | Not available | SHA-256 fingerprint comparison |
| Redirect monitoring | Status code only | Loop and host drift detection |
| False positive filtering | Alert on first check | 2-of-3 retry confirmation |
| Notifications | Email only | 6 channels with failure details |
Asset verification
MIME type checks
HTML change detection
Redirect monitoring
False positive filtering
Notifications
FAQ
Frequently asked questions
Sitewatch fetches your pages via HTTP, parses the HTML to find all referenced assets (scripts, stylesheets, images), and sends a HEAD request to each one. If an asset returns a 404, 410, 5xx, or has a mismatched MIME type, it creates an incident. The page HTML is also fingerprinted with SHA-256 to detect unexpected structural changes.
Unlikely. Sitewatch uses 2-of-3 retry confirmation. A failure must be reproduced consistently before an incident is created. Transient errors during a deploy window are filtered out. A 30-minute alert cooldown also prevents repeated notifications for the same problem.
Check intervals are configurable per site — from every 30 minutes on Free up to every 5 minutes on Pro. You can also trigger a manual check anytime from the dashboard — ideal for verifying a deploy immediately after release.
Six channels: Slack, email, SMS, webhook, PagerDuty, and Opsgenie. Per-site routing lets you send alerts to the right team. Each alert includes the incident type, affected URL, and HTTP status code.
No. Sitewatch works entirely externally by fetching your pages over HTTP and parsing the HTML. There are no scripts, SDKs, or agents to install. Setup takes about two minutes.
Explore more