Network Error Logging

Your logs only contain the visitors who got through

A request that never reached your server leaves no trace on it. Network Error Logging has the browser report the failure instead — DNS, TCP, TLS and HTTP errors, sent from the client that experienced them, about the connections you could not otherwise see.

Start Free Trial Documentation →
What's at Stake

Server monitoring is a survey of the people who arrived.

Every metric your infrastructure produces is built from requests that reached it. If a visitor's DNS resolver returned the wrong answer, their connection was refused three hops away, or your certificate failed to validate on their device, your servers recorded nothing at all — because from their point of view, nothing happened. The dashboard stays green precisely because the affected users never made it far enough to appear on it.

Survivorship Bias

Failures are invisible to the system that failed

An outage between your visitor and your edge produces no log line, no error rate and no alert. Availability measured from inside your own network can only ever tell you that the requests which arrived were served.

Partial Reach

Problems are frequently regional, not global

A misconfigured resolver at one ISP, a routing problem in one country, a certificate an older device will not trust — these affect a slice of your audience. Synthetic checks from a handful of monitoring locations will usually miss exactly that slice.

Silent Churn

Nobody reports a site that simply didn't load

A visitor who cannot reach you does not open a support ticket. They try once, get a browser error page with none of your branding on it, and go elsewhere. The commercial cost is real and the signal never arrives.

What Network Error Logging Does

Failure reports from the clients that failed

One response header asks browsers to remember problems reaching your site and report them once they can. The reports come from real visitors on real networks, describing connections your own infrastructure never saw.

Client-Side Reporting

The browser tells you what your servers could not

When a request fails, the browser records what went wrong and sends the report to your reporting endpoint — which is us, not you. That is what makes the mechanism work during an outage: your site can be entirely unreachable and the reports still arrive, because delivering them never depends on the thing that is broken.

Learn more about NEL setup →
Failure Taxonomy

Which layer broke, not just that something did

Reports name the phase and the specific error: a name that would not resolve, a connection refused or timed out, a certificate whose dates or authority did not check out, or an HTTP-level problem. That distinction is the difference between escalating to your DNS provider, your network team, or your own application.

Learn more about the Reporting API →
Built-in Sampling

A widespread outage doesn't become a flood of reports

NEL carries its own sampling controls, so you choose what fraction of successes and failures are reported. During a significant incident that keeps the volume proportionate rather than overwhelming, and on a large site it lets you hold full fidelity on failures while sampling successful requests lightly or not at all.

Learn more about Crash Reports →
Get Started

See the visitors who never arrived. From their side.

One header. No code. Error reports arrive from real client networks.

Start Free Trial Talk to our team →

30-day free trial  ·  One header  ·  No code  ·  Cancel anytime

Detection

What the browser will tell you

NEL groups failures by the phase of the connection that broke, which is usually enough to route the problem to whoever owns that layer. The specification defines a long list of error types across DNS, TCP, TLS and HTTP — these are a few of the ones you are most likely to see.

Reported type What it means
dns.name_not_resolved The visitor's resolver could not turn your hostname into an address
dns.address_changed The address resolved differently from the one previously seen
tcp.timed_out / tcp.refused The connection could not be established with your server
tls.cert.date_invalid Your certificate was expired or not yet valid on that device
tls.cert.authority_invalid The issuing authority was not trusted by that client
http.error The connection worked and the server returned an error response

Reports are sent to us rather than to you, so a visitor who cannot reach your site at all still delivers theirs — the report never needs to touch the infrastructure that is having the problem.

Architecture

One response header. No code. No crawlers.

Network Error Logging is a browser standard delivered over the Reporting API. The browser does the observing and the reporting; nothing of ours runs on your pages, and no traffic is routed through us. What you get back is a view of your own availability measured from outside your infrastructure.

One header enables it. The value is a small JSON object naming the reporting group and how long browsers should remember it.

Minimal setup — report all failures
NEL: {"report_to":"default","max_age":31536000,
  "include_subdomains":true,"failure_fraction":1.0}

NEL delivers over the Reporting API, so you will also need a Report-To group pointing at your Report URI endpoint — the exact header is on your Setup page.

No code added to your pages

No traffic routed through us

No synthetic checks from a fixed set of locations

Your site's performance is unaffected

Covers the networks your visitors actually use — mobile carriers, corporate proxies, national ISPs

Availability

The other half of your uptime picture

Server-side monitoring answers whether your infrastructure is healthy. Synthetic checks answer whether a handful of chosen locations can reach it. Neither answers the question your customers care about, which is whether they could reach it — and that answer only exists in their browsers.

NEL is how you collect it, and it costs a response header. It is at its most valuable during exactly the incidents where every other source of truth is reporting normal.

Certificate Transparency →
Scope

One layer in the stack. Here's how it fits.

NEL reports on reaching your site at all — name resolution, connection and transport. It does not tell you what happened once the page loaded, and it does not inspect content: it is the reachability layer, and it works alongside the rest.

NEL does Pairs with
Reports DNS, TCP and TLS failures Certificate Transparency for certificates issued in your name
Surfaces outages your servers never saw Crash Reports for pages that loaded and then failed
Measures availability from the client side Deprecation Reports for features about to stop working
Samples so incidents stay proportionate CSP for what executes once the page arrives

Together, these use the browser's own reporting to describe what your visitors experienced, rather than what your servers believe they served.