Skip to main content


What is Network Error Logging?

By Billy Hoffman

What if there was a way for you to know whenever a visitor had trouble connecting to your website? Imagine that whenever someone anywhere in the entire world experienced a DNS timeout, encountered an expired SSL certificate, or received a 502 Bad Gateway error when accessing your site, you instantly knew about it? Suddenly every visitor to your site forms a vast sensor network allowing you to see exactly who is having a problem, exactly where, instantly. Sounds impossible? It’s not. It’s called Network Error Logging.

How Network Error Logging Works

Network Error Logging is an emerging browser standard that allows any website visitor to alert the website owner when they encounter connectivity, network, or application errors.

Traditionally server-side approaches like Application Performance Management (APM) or backend error logging systems aren’t well-suited for detecting these types of errors, since they only log data from successful incoming requests. Everyone has seen a connection error like this:

In this case, the browser cannot connect to the site – something is closing the connection. This connectivity error means the request doesn’t even get to the server where the server-side tools could record any problem. In this example a site that only uses server-side approaches would have a blindspot and detect the problem this user is experiencing.

This is where Network Error Logging comes into play. Network Error Logging is a client-side approach, similar to Synthetic Monitoring, that allows regular website visitors to report any connectivity problems they have. And I mean anything: DNS or TCP issues, TLS configuration or certificate errors, HTTP errors from CDNs, load balancers, or reverse proxies. If you have any problem connecting, requesting, or downloading a page, Network Error Logging can report it.

Now, I know what you must be thinking:

If someone is having trouble communicating with my site, how can they communicate with me to tell me they are having problems communicating with me?

Network Error Logging works by sending special HTTP response headers to the browser which say: “I know we are clear communicating now, but if you ever have trouble connecting to this site in the future, I want you to report it to by sending a message to this other URL.”

A Network Error Logging Example

Let’s consider an example. The site starts using Network Error Logging (NEL) by including 2 response headers, the NEL header and the Report-To header. Here is the NEL header that is using:

NEL: {"max_age": 2592000", "include_subdomains":true, "failure_fraction":1.0, "report_to":"default"}

Let’s break down what each option means:

  • max_age: 2592000 For the next 30 days, the browser should use this policy when reporting errors about
  • include_subdomains: true The browser should send error reports for and any subdomain of
  • failure_fraction: 1.0 The browser should report 100% of errors it detects on This can be used to throttle how many people are reporting issues, but at the expense of potentially missing errors.
  • report_to: default This defines what reporting group to use, which is defined the Report-To header.

The site also sends this Report-To header:

Report-To: {"group":"default","max_age": 2592000,"endpoints":[{"url":""}],"include_subdomains":true}

This header is defining a new report group that will be used for NEL. Let’s break down what each option means:

  • group: default The name of our group. This is what links the NEL header to use this reporting endpoint.
  • max_age: 2592000 How long the browser should use this policy. This example is only using this for NEL if the max_age values match.
  • endpoints: ... This defines an array of URLs where the error report will be sent. Here it will use

Why is Report-To a different header? The idea is to define a standard Reporting API that other browser standards like Feature PolicyContent Security Policy, or Certificate Transparency could use to report data.

Let’s consider what happens if Melanie, a regular visitor to, has a TCP connection error like we saw in the Chrome error page above.

Because Melanie has already visited successfully in the past, her browser already knows about the NEL policy and where it should be reported. Here is what it sends:

POST /collect HTTP/1.1
Content-Type: application/reports+json

"age": 0,
"type": "network-error",
"url": "",
"body": {
"sampling_fraction": 1.0,
"referrer": "",
"server_ip": "",
"protocol": "",
"method": "GET",
"request_headers": {},
"response_headers": {},
"status_code": 0,
"elapsed_time": 212,
"phase": "connection",
"type": "tcp.refused"

This has all the critical information someone needs to troubleshoot the problem! The user experienced a tcp.refused error while trying to request The server IP that the browser was talking to was It took 212 ms from when the browser started trying to reach the URL until the error was encountered. Based on when the report was received, you know what time the problem occurred! You can even geo locate the IP address that sent the report to understand where in the world they were coming from. Read the W3C NEL Standard for more complex examples.

Going Forward with Network Error Logging

Network Error Logging is a new standard that turns every repeat visitor to your site into a sensor that can alert you to any network or application errors. While support is currently limited to Chromium-based browsers like Google Chrome and Microsoft Edge, other browsers have expressed interest in refining and adopting the standard. But that shouldn’t stop you! You can start using Network Error Logging today as a complement to other availability monitoring tools, and collect real time information about your users


Learn more about Digital Experience Monitoring