Clarity Tracking Script Fails Silently Under Strict CSP Without Dashboard Alerting

Microsoft Clarity's client-side tracking script stops transmitting session data when a site's Content Security Policy blocks its outbound requests to Microsoft collection endpoints. The script does not surface a visible error to the end user, and the Clarity dashboard does not currently expose a built-in metric or alert that indicates a measurable drop in recorded sessions caused by CSP violations.

Administrators must rely on manual browser console inspection to detect connect-src directive rejections, but this approach does not scale across traffic volumes. Additionally, browser extensions and network-level ad blockers can produce identical silent failures, making it difficult to distinguish CSP misconfiguration from external filtering without correlating server-side header logs.

The absence of an automated signal means a site can operate with a restrictive CSP for extended periods while believing Clarity is functioning normally.

• Does Clarity expose any programmatic hook or webhook that fires when the tracker detects its own network requests being blocked?
• Is there a recommended pattern for instrumenting a custom health check that distinguishes CSP rejections from ad-blocker interference using only client-side signals?