A visitor loads your checkout page. A third-party script violates your Content Security Policy and fails to load. The payment form breaks. The visitor leaves. You never find out because the error happened in their browser, not on your server. Your server logs show a clean 200 response. Your uptime monitor says everything is fine.
The Reporting API exists to close this gap. It tells browsers to send structured error reports back to an endpoint you control, automatically, without the visitor needing to do anything. CSP violations, network errors, browser deprecation warnings, and certificate transparency issues can all be reported before they become customer complaints.
What gets reported
CSP violations are the most common use case. When a script, stylesheet, or resource gets blocked by your Content Security Policy, the browser can send a report containing the blocked URL, the violated directive, and the page it happened on. Without reporting, CSP violations are silent. You set a strict policy, something breaks, and you only find out when someone files a support ticket.
Network Error Logging (NEL) captures DNS failures, TCP connection errors, and TLS handshake failures that happen between the visitor's browser and your server. These are the errors that don't show up in server logs because the connection never reached your server.
Deprecation reports tell you when visitors' browsers encounter deprecated APIs on your page. If you're using a JavaScript API that Chrome plans to remove, the Reporting API warns you months before it breaks.
The two versions
The Reporting API has gone through two versions. The original used a Report-To header with a JSON group definition. The newer version uses Reporting-Endpoints, which is simpler and better supported. Most sites need only the newer version, but some browsers still use the old one, so ideally you configure both.
The CSP report-to directive replaced the older report-uri directive. If you're still using report-uri, it works but is deprecated. The modern setup uses report-to pointing at a named endpoint defined in the Reporting-Endpoints header.
What the audit checks
The Reporting API Audit fetches your page's HTTP headers and checks for:
Report-To header (v1) presence and valid JSON structure. If the JSON is malformed, browsers silently ignore it and you get zero reports.
Reporting-Endpoints header (v2) presence and syntax. This is the current standard and should be present on any site running CSP.
CSP report-to wiring. Having a Reporting-Endpoints header isn't enough. Your CSP directive needs to reference it by name. The audit checks that the name in report-to matches a defined endpoint.
NEL header presence. Network Error Logging is opt-in and most sites skip it, which means DNS and TLS errors in production go entirely unmonitored.
COEP Report-Only. Cross-Origin Embedder Policy can be deployed in report-only mode first, which sends violation reports without actually blocking resources. This is the safe way to roll out COEP, and the audit checks whether you're using it.
If you're building a monitoring stack for a portfolio of sites, The $100 Network ($9.99 on Kindle) covers how to set up automated health checks that include header verification.
Fact-check notes and sources
- The Reporting API v2 (Reporting-Endpoints) is specified in the W3C Reporting API specification. Source: W3C, "Reporting API."
- CSP
report-uriis deprecated in favor ofreport-to. Source: MDN Web Docs, "Content-Security-Policy: report-uri." - Network Error Logging (NEL) is specified in the W3C NEL specification. Source: W3C, "Network Error Logging."
- Chrome, Edge, and Opera support the Reporting API. Firefox has partial support. Safari does not support it as of 2025. Source: caniuse.com.
Related reading
- CSP strictness audit — getting your Content Security Policy right
- Modern security headers — the full header stack
- Cross-origin isolation audit — COEP and COOP configuration
- Serverless posture audit — monitoring your function endpoints
This post is informational, not security-consulting advice. Mentions of Chrome, Firefox, Safari, W3C, and other third parties are nominative fair use. No affiliation is implied.
