- last edited on by
MaciejNeumann
Hello,
We monitor a high-traffic e-commerce web frontend. The site sits behind a CDN that injects a Content-Security-Policy-Report-Only header for script monitoring. As a result, the RUM JavaScript captures a large number of CSP violations. Almost none of them are actually enforced:
This noise inflates the error rate in Experience Vitals (CSP violations show up at roughly 2–4K/min), and it makes the real errors hard to see.
What we need
We want to exclude report-only CSP violations (csp.disposition == "report") from Grail and from the frontend error KPIs. We want to keep the enforced ones, because they are the only violations that actually impact users.
What we configured
In OpenPipeline → User events:
- A dynamic route in first position, with the matching condition characteristics.has_csp_violation == true and csp.disposition == "report", pointing to a dedicated pipeline.
- In that pipeline, a single processing stage with a Drop record processor.
What we observe
- The drop works on the event side. In the error detail view (e.g. a report-only violation on one of our first-party URLs), occurrences stop exactly when the pipeline was activated (~11:30). DQL on user.events confirms the report-only events are no longer stored.
- The metric dt.frontend.error.count (error.type == "csp") is not affected. The Experience Vitals Performance → Error rate → CSP rule violation chart keeps the same level (2–4K/min) after 11:30.
Questions
- Is dt.frontend.error.count extracted before or independently of OpenPipeline routing and processing for user events? Is it expected that a drop processor doesn’t affect it?
- Is there a supported way to exclude report-only CSP violations from this metric and from the Experience Vitals error rate?
- If not, would the recommended approach be to build our own error-rate metric (e.g. a metric extraction in OpenPipeline filtered on csp.disposition == "enforce") and use it for dashboards and alerting?😓
Thanks in advance for any insight!
Featured Posts
