Wiki · Concept · Last reviewed June 25, 2026

Network Error Logging

Network Error Logging is browser infrastructure for reporting network failures that ordinary server logs may never see.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser security, telemetry, network errors, observability, agents

Definition

Network Error Logging, or NEL, is a W3C Web Performance Working Group mechanism that lets a web application declare a network-error reporting policy for an origin. The W3C Working Draft says a user agent can use that policy to report network errors that prevented requested resources from being fetched successfully. MDN describes NEL as an experimental HTTP response-header mechanism for reports about failed, and optionally successful, network fetches from supporting browsers.

NEL fills a gap that ordinary server logs cannot fill. If DNS resolution fails, a TCP connection times out, a TLS handshake fails, or a connection is reset before the application can respond, the server may have no request to log. NEL moves part of that observation point into the browser.

How It Works

A site opts in by sending a JSON-encoded NEL response header. The core members are report_to, which names the reporting group, and max_age, which sets the policy lifetime in seconds. MDN also documents include_subdomains, success_fraction, and failure_fraction. By default, successful requests are not reported when success_fraction is absent, while failed requests are reported when failure_fraction is absent.

The W3C draft defines NEL report generation only for potentially trustworthy origins. It also defines report fields such as sampling fraction, elapsed time, phase, and type. Error families include DNS resolution errors, secure connection establishment errors such as TCP and TLS failures, and request-or-response transmission errors such as HTTP errors, redirect loops, aborted fetches, and unknown failures.

NEL is delivered through reporting infrastructure. The W3C draft says the policy instructs the user agent to attempt delivery to endpoints previously configured using the Reporting API. MDN's current guide describes NEL reports as sent to a reporting group defined in a Report-To header.

Agent Context

Network errors matter for browser agents because agents often turn broken network paths into repeated attempts, fallbacks, and silent substitutions. A human may stop when a payment provider fails or a login widget does not load. An agent may retry, choose a cached path, click an alternative link, or continue with partial page state.

NEL can show that an agent's experience was not the same as the server's view. The server may see no failed checkout request, while the browser reports a DNS, TCP, TLS, HTTP, or redirect-loop failure. For audits of delegated browsing, this distinction matters: absence from the application log is not proof that the browser did not attempt the action.

Governance Use

NEL is useful when it is tied to narrowly scoped operational questions: did users in a region fail to reach a service, did a certificate problem interrupt an identity flow, did a redirect loop affect an agent task, or did a first-party widget fail when embedded in a third-party context? The W3C draft explicitly includes use cases for navigation failures, first-party subresource fetch failures, and third-party subresource fetch failures.

For agent systems, NEL should be paired with task logs, browser version, profile or container, network partition context, and human approvals. It should not be treated as a complete record of intent. A report can show a failed fetch; it cannot tell whether the user authorized the next retry, whether the model inferred a workaround, or whether another connector supplied the missing data.

Limits

NEL creates privacy risk as well as reliability insight. The W3C privacy section says reports could expose information about a user's network configuration, and warns that stored NEL policy could be abused as a persistent identifier. The draft mitigates those risks by restricting registration and delivery to potentially trustworthy origins and by partitioning the NEL policy cache with the network partition key.

NEL is also not universal browser evidence. MDN marks it experimental and warns developers to check browser compatibility before production use. Reports are sampled, policy-limited, implementation-dependent, and delivered through reporting mechanisms that may themselves fail. Use NEL as one signal, not as an audit guarantee.

Minimum Evidence Record

For agent-mediated browsing, preserve the origin, task identifier, NEL policy value, reporting group, policy lifetime, sampling fractions, report phase, report type, elapsed time, request URL after stripping secrets, browser and version, top-level site or container where available, and whether the report was received server-side or observed locally. Avoid retaining full query strings, account identifiers, tokens, IP-derived user profiles, or raw headers unless an incident investigation requires them.

Source Discipline

Use the W3C Network Error Logging draft for the policy model, error taxonomy, report fields, sampling, and privacy considerations. Use MDN for implementation-oriented guidance and compatibility cautions. Use Reporting API sources when discussing endpoint configuration and delivery, not as a substitute for the NEL specification.

Spiralist Reading

Spiralism reads NEL as testimony from the path itself. A failed request is usually invisible to the institution that would have answered it. The browser carries back the news that the road broke before the door.

The agent-era lesson is modest: network failure is part of agency. A delegated system should not hide degraded paths behind fluent retries. It should know when the route failed, record that fact narrowly, and avoid turning reliability telemetry into a permanent map of the user's network life.

Sources

Return to Wiki