# Network error (/en/docs/web-security/reporting-api/reports/network-error)



A `network-error` report describes a request that failed (or succeeded, when
sampled) at the network level: a DNS failure, a TCP or TLS error, a reset
connection, or an HTTP error. Because these failures often never reach your own
logs, [Network Error Logging (NEL)](/en/docs/web-security/policies/network-error-logging) is the way to see them from the client's
perspective.

<Callout type="warn" title="Experimental, and tied to the legacy header">
  NEL is Chromium-only and is the one report type that still requires the deprecated `Report-To` header. `Reporting-Endpoints` does not deliver NEL. See [Network Error Logging](/en/docs/web-security/policies/network-error-logging).
</Callout>

## When the browser sends it [#when-the-browser-sends-it]

On a request failure, or on a successful request when the configured
`success_fraction` samples it. The `NEL` header's `failure_fraction` and
`success_fraction` control how much is reported, so failures are usually captured at
full rate and successes sampled lightly or not at all.

## Setup [#setup]

```http
Report-To: {"group":"nel-group","max_age":31536000,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}
```

```http
NEL: {"report_to":"nel-group","max_age":31536000,"include_subdomains":true,"failure_fraction":1.0}
```

## Payload example [#payload-example]

```json
{
  "type": "network-error",
  "age": 20,
  "url": "https://example.com/bad-request",
  "user_agent": "Mozilla/5.0 ...",
  "body": {
    "sampling_fraction": 1,
    "referrer": "https://example.com/previous-page",
    "server_ip": "192.0.2.172",
    "protocol": "http/1.1",
    "method": "POST",
    "request_headers": {},
    "response_headers": {},
    "status_code": 400,
    "elapsed_time": 338,
    "phase": "application",
    "type": "http.error"
  }
}
```

## Field reference [#field-reference]

| Field               | Meaning                                                                                    |
| ------------------- | ------------------------------------------------------------------------------------------ |
| `sampling_fraction` | The rate at which this outcome was sampled (0 to 1).                                       |
| `referrer`          | The referrer of the failed request.                                                        |
| `server_ip`         | The resolved server IP, or `""` if none.                                                   |
| `protocol`          | The protocol used, for example `http/1.1`.                                                 |
| `method`            | The HTTP method.                                                                           |
| `request_headers`   | Request headers the `NEL` policy opted to include, keyed by name.                          |
| `response_headers`  | Response headers the `NEL` policy opted to include, keyed by name.                         |
| `status_code`       | The HTTP status, or `0` when there was no response.                                        |
| `elapsed_time`      | Time to the failure, in milliseconds.                                                      |
| `phase`             | Where it failed: `dns`, `connection`, or `application`.                                    |
| `type`              | The specific error code, for example `dns.name_not_resolved`, `tcp.refused`, `http.error`. |

The `phase` is the quickest triage: `dns` points at name resolution, `connection`
at TCP or TLS, and `application` at an HTTP-level error.

## How to receive it [#how-to-receive-it]

Pair the `NEL` header with a `Report-To` group (NEL does not work with
`Reporting-Endpoints`). Point the group's endpoint at CentralCSP to collect the
[network-error stream](/en/docs/platform/monitoring/nel) alongside your other
reports.

## What it tells you about security [#what-it-tells-you-about-security]

Most network errors are availability signals, but patterns matter: a cluster of TLS
or certificate failures from one region can indicate interception or a captive
portal, and a surge of DNS or connection failures is an availability and integrity
signal worth investigating before users complain.

## Gotchas [#gotchas]

The body field names are snake\_case, unlike the camelCase policy-violation reports.
NEL is HTTPS-only, and it is not delivered through `Reporting-Endpoints`, only the
legacy `Report-To` header, which is the one place that header is still required.

## Browser support [#browser-support]

Chromium-based browsers only (Chrome, Edge, Opera). Firefox and Safari do not
implement NEL, and Mozilla holds a negative standards position citing privacy.

## See also [#see-also]

* [Network Error Logging (NEL)](/en/docs/web-security/policies/network-error-logging)
* [Report-To header](/en/docs/web-security/reporting-api/headers/report-to)
* [Report-To vs Reporting-Endpoints](/en/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints)
* [NEL monitoring in CentralCSP](/en/docs/platform/monitoring/nel)
* [The report delivery format](/en/docs/web-security/reporting-api/concepts/report-delivery-format)

## Sources [#sources]

* [MDN, Network Error Logging](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Network_Error_Logging)
* [W3C, Network Error Logging](https://www.w3.org/TR/network-error-logging/)
* [web.dev, Network Error Logging](https://web.dev/articles/network-error-logging)