Network Error Logging reports

Network Error Logging (NEL) enables web applications to declare a reporting policy that can be used by the browser to report network errors for a given origin. DNS resolution errors, secure connection errors, HTTP errors like 404s, redirect loops etc. But you can even get HTTP 2xx, 3xx success reports, if you wish.

The `NEL` response header:

NEL: {"report_to":"default","max_age":1800,"include_subdomains":true}

report_to: name of the group where to send NEL reports to (that's an underscore, unlike in the Content-Security-Policy header)
max_age: the lifetime of this NEL policy in seconds, set to weeks or months eventually to also get reports from browsers that have not visited the site for some time
include_subdomains: optional, whether this policy applies to all subdomains of the current domain
- Used only for errors that occurred during DNS resolution, not for errors that occurred in other phases (connection, application)
- This means that even if the browser has an include_subdomains: true NEL policy cached for https://example.com, it will not generate reports for expired certificate on https://expired.example.com because these errors happen in the connection phase
- …but will send a report for an expired certificate on https://example.com

The header can also contain these optional fields, both are a number between 0.0 and 1.0:

success_fraction: defines a sampling rate to limit the number of "successful" reports sent by the browser, by default no such reports are sent
failure_fraction: defines a sampling rate to limit the number of "failure" reports sent by the browser, all such reports are sent by default

The `Report-To` response header:

Report-To: {"group":"default","max_age":1800,"endpoints":[{"url":"https://pliny.has.report/report"}],"include_subdomains":true}

group: the name of the group, the same as in the NEL header
max_age: how long the browser should use the endpoint and report errors to it
endpoints: reporting endpoint configuration, can specify multiple endpoints but reports will be sent to just one of them
- url: where to send reports to, must be https://, otherwise the endpoint will be ignored

Generate HTTP 404

, e.g. https://canhas.report/fran-lena-is.404

show the code ▼

<code id="url">https://canhas.report/fran-lena-is.404</code>
<script>
  document.getElementById('http').onclick = function() {
    new Image().src = document.getElementById('url').textContent;
    alert('HTTP 404 generated');
  }
</script>

Will trigger a report that will be sent asynchronously, possibly grouped with other reports (HTTP 404 visible in Developer Tools in the Console tab, you won't see the report in Network tab but you can still view the reporting requests)
Check your reports (can take some time before the browser sends the report)

Generate DNS resolution error

, e.g. https://cheezburger.canhas.report

show the code ▼

<code id="cheezburger">https://cheezburger.canhas.report</code>
<script>
  document.getElementById('dns').onclick = function() {
    new Image().src = document.getElementById('cheezburger').textContent;
    alert('DNS resolution error generated');
  }
</script>

Will trigger a report that will be sent asynchronously, possibly grouped with other reports (resolution error visible in Developer Tools in the Console tab, you won't see the report in Network tab but you can still view the reporting requests)
Check your reports (can take some time before the browser sends the report)

Generate TLS certificate error

One of the most useful NEL report types could be TLS error reports. Things like expired certificate sometimes happen even if you automate renewal and NEL offers an easy way to monitor for such issues. Now, testing TLS NEL reports is not exactly easy and cannot be done with just a few clicks here. The reason is that the browser needs to cache the NEL policy for the host first, and for that it needs a working and secure HTTPS connection (i.e. no errors). And then the same browser needs to encounter an error when loading a page using HTTPS from the same host, not even from the host's subdomain – that's because include_subdomains: true doesn't apply for the connection phase of the request for privacy reasons, and the connection phase is exactly where secure connection establishment errors occur. But you can…

Simulate a TLS error with Fiddler

Fiddler is a great HTTP debugging proxy originally written by Eric Lawrence and you can use it to inspect HTTP and HTTPS traffic (and much more). We'll use it to generate a TLS error in your browser. Although it would be possible to simulate an expired certificate with Fiddler, let's take the slightly easier path and simulate a certificate issued by an untrusted certification authority:

Get Fiddler
Load this page to cache the NEL policy – somehow I think you've already done this step
Configure Fiddler to decrypt HTTPS traffic but DO NOT trust the Fiddler Root Certificate
Load this page again and this is what's going to happen:
1. Your browser will send a request to the Fiddler proxy
2. The proxy will resend it to the server
3. The server will respond to Fiddler, encrypting the traffic with a valid certificate
4. Fiddler will validate the certificate produced by the server and decrypt the traffic
5. Fiddler will re-encrypt the traffic with it's own Root Certificate
6. But your browser doesn't trust the Root Certificate and will show an Invalid Certification Authority error or similar
7. Your browser will also generate the NEL report
Exit Fiddler now (or stop capturing traffic using F12) before your browser will try to actually send the generated report
Check your reports (can take some time before the browser sends the report)
You should see a network-error report with "type": "tls.cert.authority_invalid", "phase": "connection" and if this would be a report for an expired certificate, you'd see tls.cert.date_invalid type

See also Chrome's list of all NEL types.

Related specs & documents

Network Error Logging Working Draft
Reporting API Working Draft
- Reporting API Editor's Draft (which will evolve into a Working Draft, followed by a Recommendation eventually)
- Notable changes in the Editor's Draft are switching to structured headers (Reporting-Endpoints instead of Report-To) and moving out concrete reports into the following separate Draft Community Group Reports: Crash Reporting, Deprecation Reporting, Intervention Reporting