Third-Party Script Monitoring

You can manually open your browser's DevTools Network tab, reload the page, and inspect every external script for its status code and content type — but that's a one-time snapshot you'd have to repeat constantly. Sitewatch automates it: paste your URL and it parses your HTML, discovers every third-party script, and checks each one's HTTP status and MIME type on a schedule. No DevTools, no manual audits, no code on your site.

Add your site to Sitewatch and every monitoring cycle re-discovers and re-checks all external scripts referenced in your HTML. Because vendors change endpoints and have outages without warning, continuous checks are the only reliable way to catch a script that worked yesterday and 404s today. Intervals are configurable per site, from every 30 minutes on Free to every 5 minutes on Pro.

When an external script returns an error status (404, 410, 5xx), is served with a non-JavaScript MIME type, or redirects to an unexpected destination, the browser stops executing it — and whatever feature depended on it silently breaks. Sitewatch confirms the failure with 2-of-3 retries to filter transient blips, then raises an incident naming the script URL, status code, MIME type, and affected page.

Yes. Analytics tags (Google Analytics, Segment, Mixpanel) and chat widgets (Intercom, Drift, Zendesk) are loaded as external scripts, so they fall directly inside Sitewatch's coverage. If the analytics script starts 404ing and your data goes dark, or the chat widget script fails to load and support messages stop arriving, Sitewatch catches the failed request even though the page itself still looks fine.

Yes. A third-party script referenced over http:// on an https:// page is mixed content, and browsers block it outright — the feature it powers disappears with no error visible to you. Sitewatch flags insecure references and protocol issues; see mixed-content monitoring for the dedicated protocol-level checks that pair with per-script monitoring.

Yes. When an individual script file errors, per-script monitoring catches it. When an entire vendor domain goes dark — DNS failure, expired cert, total outage — third-party dependency monitoring catches it at the domain level. Either way, you get an alert across your configured channels (6 channels including Slack, email, and PagerDuty) before your customers tell you.

Sitewatch monitors every external script referenced in your page HTML -- analytics (Google Analytics, Segment, Mixpanel), payment forms (Stripe, PayPal), chat widgets (Intercom, Drift), ad tags, tag managers, and any other third-party JavaScript. Scripts are discovered automatically by parsing the HTML.

No. Sitewatch checks the HTTP status code and MIME type of each script -- verifying that it loads and is served as JavaScript. It does not download, hash, or compare script contents between checks. It catches availability failures and delivery errors, not content-level changes.

Sitewatch detects scripts returning error status codes (404, 5xx), scripts served with wrong MIME types (e.g., a CDN serving text/html instead of application/javascript), and scripts that have been removed or relocated. Detecting these failures is part of Sitewatch's 20 detection rules covering the full range of up-but-broken issues.

When Stripe.js (or any script) returns an error status code or wrong MIME type, Sitewatch confirms the failure with 2-of-3 retries and sends an alert across your configured channels -- 6 channels including Slack, email, and PagerDuty. The alert includes the script URL, HTTP status code, and which page is affected.

No. Sitewatch monitors your pages externally using HTTP requests. It discovers and checks all scripts automatically by parsing the HTML -- no code changes, no tags to install, no vendor integrations required.