When a website fails to load, its operator may see nothing. The request might have stopped during DNS lookup, connection setup, TLS negotiation, or response delivery—before the application's own logging code ever ran. Network Error Logging, or NEL, is designed to fill that blind spot.
NEL lets a secure website ask supporting browsers to collect sampled reports about network outcomes and send them to a configured reporting endpoint. That can improve reliability, but it also creates stored browser policy and background telemetry. The privacy details matter as much as the diagnostics.
How a site opts in
A server sends an NEL response header containing a JSON policy. The policy names a reporting group, sets a lifetime through max_age, and can define sampling fractions for failed or successful requests. A companion reporting configuration tells the browser where reports should go.
MDN describes NEL as experimental and advises checking browser compatibility. A site cannot assume that every visitor will store the policy or deliver reports.
What kinds of failures can be reported
The W3C Network Error Logging specification groups failures by phase. A DNS error happens while resolving a hostname. A connection error can occur while establishing TCP, QUIC, or a secure connection. An application-phase error can involve HTTP protocol problems, response corruption, redirect loops, or unsuccessful status codes.
This structure helps operators distinguish “the server returned an error page” from “the browser never reached the server.” The second case is otherwise difficult to measure because the server has no request to log.
What a report may contain
A network error report can include the requested URL, the error type, the phase, elapsed timing, method, protocol, response status, and the server IP address where relevant. The exact fields depend on the event and browser implementation.
Those details are useful for diagnosing regional DNS failures, broken certificates, routing problems, load-balancer issues, and content-delivery outages. They can also reveal sensitive URL paths or identifiers if a service places secrets in URLs. Developers should avoid capability tokens and personal data in URLs regardless of NEL.
Why sampling matters
A high-traffic service does not need a report for every request to detect a widespread outage. NEL policies can sample failures and, optionally, successes. Failure sampling helps capture uncommon problems without generating a second stream of traffic equal to the first.
Successful reports provide a baseline, but they also expand collection. A responsible deployment chooses the smallest fraction that answers an operational question, keeps retention short, and does not treat network diagnostics as a general behavioral analytics channel.
Reports can arrive after the original page is gone
NEL uses the browser's Reporting API infrastructure. Reports can be queued and delivered later rather than blocking the failed request. This resembles the performance principle behind the Beacon API, though the trigger and report format are different.
Our guide to the Beacon API and background sends explains page-initiated delivery. NEL is driven by a stored origin policy and network outcomes observed by the browser.
The privacy risks are real but bounded
The specification notes that error reports could expose information about a user's network configuration. A malicious design might try to probe internal services or encode a per-user reporting address into a long-lived policy. That unique policy could act like a supercookie.
Mitigations restrict policy registration and report delivery to potentially trustworthy origins. Reports should not disclose information beyond what the relevant server could observe when processing the request. For example, the report does not identify which DNS resolver the user employed.
The specification also requires stored NEL policies to be cleared when users clear browsing data such as cookies, site data, or history. This ties diagnostics policy to the same broad reset expectations as other site state.
First-party and third-party contexts
An origin can register a policy when it is loaded directly or as a resource on another page, subject to browser rules. This lets a content-delivery or asset host diagnose failures affecting embedded scripts, fonts, or images.
It also means that diagnostics may involve parties other than the website visible in the address bar. Operators should prefer collectors they control, document outside processors, and avoid sending full sensitive URLs to unrelated services.
NEL is not a complete monitoring system
Unsupported browsers, blocked reporting endpoints, offline devices, sampling, and expired policies all create gaps. A queued report may never arrive. Operators still need server logs, synthetic monitoring, application metrics, and user reports.
NEL also does not tell a site everything about the user's network. It is designed to describe request failures, not reveal Wi-Fi names, browsing history, or other applications. Browser privacy protections and request blocking can further limit delivery.
What users can do
Keep the browser updated
Reporting behavior and privacy safeguards are implementation details that evolve. Current versions receive security fixes and standards changes.
Clear site data when resetting trust
Clearing browsing data can remove stored reporting policies along with cookies and other site state. Our guide to site-controlled data clearing explains a related mechanism, while the browser's settings give the user broader control.
Limit unnecessary reporting destinations
Tracker blocking can prevent connections to recognized telemetry and analytics endpoints. It cannot guarantee that every first-party reporting service is harmless, but it reduces exposure to known third-party infrastructure. See our tracker-blocking overview for the practical limits.
Diagnostics should remain diagnostics
Network Error Logging can reveal outages that ordinary server logs miss. That makes websites more reliable for people experiencing DNS, connection, and response failures. The responsible version is sampled, short-lived, securely delivered, and narrowly retained. A tool created to diagnose broken connections should not quietly become a durable identity or behavioral record.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.