When users experience severe connectivity failures—such as DNS resolution failures, TLS certificate mismatches, or TCP connection timeouts—the web page fails to load entirely. Because client-side JavaScript monitoring scripts cannot execute when network transport breaks down, these critical dropouts remain invisible to traditional analytics platforms. Network Error Logging (NEL), working in tandem with the W3C Reporting API, solves this visibility gap. When configured, Google Chrome captures low-level transport errors and autonomously uploads structured JSON diagnostic reports to your telemetry collector upon reconnecting.
Understanding Reporting API v1 and NEL Directives
Deploying NEL requires issuing two coordinated HTTP response headers:
Reporting-Endpoints: Defines the named collector endpoints where Chrome should upload out-of-band JSON payloads.NEL: Configures the logging policy, sampling rate, failure types, and policy cache duration (max_age).- Persistence: Once received, Chrome stores the NEL policy locally across browser restarts for the duration specified in
max_age. If subsequent requests to your domain encounter catastrophic DNS or routing drops, Chrome caches the failure reports and transmits them as soon as connectivity resumes.
Configuring Production HTTP Headers for NEL
Configure your web server to deliver the Reporting-Endpoints and NEL headers with all HTTPS traffic:
# Nginx server block configuration
add_header Reporting-Endpoints 'telemetry="https://telemetry.example.com/nel-reports"' always;
add_header NEL '{"report_to":"telemetry","max_age":2592000,"include_subdomains":true,"failure_fraction":1.0,"success_fraction":0.01}' always;
# Apache HTTP Server (.htaccess / virtual host)
Header always set Reporting-Endpoints 'telemetry="https://telemetry.example.com/nel-reports"'
Header always set NEL '{"report_to":"telemetry","max_age":2592000,"include_subdomains":true,"failure_fraction":1.0,"success_fraction":0.01}'
Examining NEL JSON Payload Structures
When an error occurs, Chrome dispatches a payload formatted according to the Report API specification:
{
"age": 12,
"type": "network-error",
"url": "https://example.com/api/data",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
"body": {
"sampling_fraction": 1.0,
"server_ip": "93.184.216.34",
"protocol": "h2",
"method": "GET",
"status_code": 0,
"elapsed_time": 450,
"phase": "connection",
"type": "tcp.timed_out"
}
}
The body.type field precisely reveals whether the breakdown occurred at the DNS stage (dns.name_not_resolved), TLS stage (tls.cert.authority_invalid), or TCP stage (tcp.timed_out).
Auditing Reporting API Payloads in Chrome DevTools
To inspect active reporting policies and view queued error payloads in Google Chrome:
- Open Google Chrome and navigate to your website.
- Open Chrome DevTools by pressing Ctrl + Shift + I (or Option + Command + I on macOS).
- Switch to the Application tab and locate the Background Services category.
- Select Reporting API. Chrome displays all registered reporting endpoints, expiration timestamps, and status details.
- Inspect the Reports table to view queued or dispatched network error payloads, verifying that failure events trigger automated transmissions seamlessly.