Historically in web development, once a site was published, and users were happy accessing content, the only visibility we would see were access logs, recording each item being fetches from the servers we control.
Over time, web developers added JavaScript tracking codes, which as with Google Analytics, which would record data to a dedicated endpoints that would then produce analytics reports.
And that’s where things stopped for a long time.
The user experience, or any issues they get, were never seen. If a JavaScript exception happened out on the Internet with a user, the developers would almost never hear about it unless that person submitted a bug report or kicked up a fuss on social media — enough to get someone’s attention. Occasionally sites would have a security.txt document that would list a security contact, to avoid the issue of tracking down someone within an organisation how actually knows how the web site works and who is responsible.
However, over the last 10+ years the state of error reporting in the browser has matured, but very few sites have publicly implemented it at this time. This is NEL: Network Error Logging.
I say publicly, as the error reporting is also useful to implement in development and test environments, for developers to get their hands on reports.
Support for collecting and submitting NEL has been improving, as shown in https://caniuse.com/mdn-http_headers_nel. Still we don’t yet see Firefox or Safari implementing this yet as at 2026…
I have written and released (Creative Commons) a set of tools on GitHub that help you implement and test NEL.
What will NEL tell me?
- DNS Phase (dns): Errors that occur during domain name resolution.
- dns.unreachable: The user’s DNS server is unreachable.
- dns.name_not_resolved: The DNS server responded but could not resolve an IP address.
- dns.failed: DNS lookup failed for other reasons (e.g., SERVFAIL).
- dns.address_changed: DNS address changed unexpectedly.
- Connection Phase (connection): Errors during TCP/TLS or socket establishment.
- Examples include TCP connection timeouts (tcp.timed_out), refused connections (tcp.refused), or TLS/certificate validation errors (tls.cert.authority_invalid).
- Application Phase (application): Errors occurring during the transmission or reception of HTTP request and response data (including HTTP 4xx and 5xx status codes or protocol errors).
- Unknown Phase (unknown): Unclassified or general network drop-offs.
The NEL Endpoint
One of the first things you need is an endpoint to receive your reports. You can have as many of these as you like, such as for production environments versus non-production.
The NEL endpoint I have templated is standard HTTPS service listening to the network for a submission, with a custom hostname and a matching, valid TLS certificate.
My implementation to stand up in an AWS account from the CloudFormation template put reports that are submitted into a DynamoDB table. The operational cost of this should only be a few cents per month: its a Serverless implmentation.
Simulating NEL Reports to the Endpoint
The second thing you may want is to send some test submissions into your NEL server, as in the real world, these come in when they are ready. You can point this script at your own endpoint, and confirm that reports are being accepted and populated into your table.
If you want to force YOUR OWN Chrome browser to send reports in more rapidly, then run the Chrome executable with the flag –short-reporting-delay, as shown https://developer.chrome.com/docs/capabilities/web-apis/reporting-api.
Checking your Server HTTP Headers for NEL
Actually, you’ll need at least two headers: the NEL header, and then either the older Report-To, or the newer Reporting-Endpoints header. So the third item I am releasing is something that connects to your web site, and inspects the configuration of these headers.
Tuning the number of reports
There’s two tuning variables you can set in the NEL header: success_fraction, and failure_fraction. Each of these are a float number between 0 and 1, and they default to zero. If you want to see a sample of the failures that your clients are seeing, then increase that to a non-zero value: in your non-production environments, you could use 1. In the real world production, you probably only want to get 1% of error reports, depending on the volume of traffic you receive from the web. You can tune accordingly.
Get these on GitHub
You’ll find the three items in GitHub: https://github.com/JamesBromberger/network-error-logging-tools
Why use these?
In production – wouldn’t you like to get reports from the real world users, instead of being in the dark about any problems your clients are experiencing? This reminds me of a quote from Ian Fleming’s James Bond: Golden Eye:
Bond: Are these pictures live?
M: Yes, unlike the Americans, we prefer not to get our bad news from CNN.
In Non-production: this can help diagnose issues you are seeing with your deployments, and (as above) perhaps to a dedicated NEL endpoint for non-production sites. Adjust the Reporting-Endpoints URLs accordingly.



