NGINX Metrics Reference

This is the complete reference of NGINX metrics collected by the Amplify Agent. Each metric is a time series you can chart on a dashboard, add to an alert rule, or query through the API. The names below are exactly what you will see in the graph picker and alert editor, so you can use this page to look up what any series means and how to read it.

How NGINX metrics are collected

The agent gathers connection and request counters from NGINX's built-in stub_status endpoint and derives response, timing, and upstream series by parsing your access logs. Counters are sampled once per minute and stored as rates or running totals, so a value like nginx.http.request.current reflects the per-second throughput averaged over the sampling window rather than a single instant. See Configuring NGINX for the exact stub_status and log-format setup the agent expects.

Connection Metrics

Connection metrics come straight from stub_status and describe how many TCP connections NGINX is handling right now and how it has handled them over time. They are the first place to look when you want to understand load: a growing gap between accepted and handled connections, or a climbing waiting count, tells you how keep-alive and worker capacity are holding up under traffic.

Metric	Description
nginx.http.conn.active	Current active connections
nginx.http.conn.reading	Connections reading request
nginx.http.conn.writing	Connections writing response
nginx.http.conn.waiting	Keep-alive connections waiting
nginx.http.conn.accepted	Total accepted connections
nginx.http.conn.dropped	Dropped connections

Request Metrics

Request metrics track throughput and the volume of data NGINX serves. Watch nginx.http.request.current to see how request rate tracks your traffic patterns across the day, and pair nginx.http.request.body_bytes_sent with your bandwidth graphs to catch large-payload endpoints or unexpected transfer spikes. These are the series most teams put front and centre on a monitoring dashboard.

Metric	Description
nginx.http.request.count	Total requests processed
nginx.http.request.current	Requests per second
nginx.http.request.body_bytes_sent	Response body bytes sent

Response Code Metrics

Response code metrics count how many responses NGINX served in each HTTP status class, derived from your access logs. Read them as ratios rather than raw numbers: a healthy site is dominated by the 2xx series, and it is the shape of the curve that matters. A sudden shift in the mix — 5xx climbing after a deploy, 404s spiking from a bad link or a crawler, a jump in 3xx after a redirect change — is what you build alerts and dashboards around. The counters below are grouped both by class (2xx, 3xx, 4xx, 5xx) and by the individual codes that are most useful to watch, plus a matching set for responses coming back from your upstream servers.

Metric	What it counts
nginx.http.status.2xx	Responses served in the 2xx (success) class — normally the bulk of your traffic.
nginx.http.status.3xx	Responses served in the 3xx (redirect) class, such as cache revalidation and URL redirects.
nginx.http.status.4xx	Responses served in the 4xx class, covering client-side conditions like bad or unauthorized requests.
nginx.http.status.5xx	Responses served in the 5xx class — the key reliability signal to alert on.
nginx.http.status.403	Responses served with HTTP 403. Track it to see access-control rejections and blocked clients.
nginx.http.status.404	Responses served with HTTP 404. A rising rate usually points to broken links or bots probing for paths.
nginx.http.status.500	Responses served with HTTP 500. Watch for spikes right after a release — typically an application-level fault.
nginx.http.status.502	Responses served with HTTP 502, when NGINX received an invalid reply from an upstream.
nginx.http.status.503	Responses served with HTTP 503, often during upstream maintenance or when a backend is at capacity.
nginx.http.status.504	Responses served with HTTP 504, when an upstream did not reply within NGINX's configured timeout.
nginx.upstream.status.2xx	2xx responses returned to NGINX by your upstream servers.
nginx.upstream.status.4xx	4xx responses returned to NGINX by your upstream servers.
nginx.upstream.status.5xx	5xx responses returned to NGINX by your upstream servers — compare against the front-end 5xx series to tell whether faults originate at the edge or the backend.

Putting these metrics to work

Every metric on this page can be charted and alerted on. Add the series that matter to a custom board on the Dashboards page, then set thresholds on the Alerts page so you hear about a change in the response mix or a connection pile-up before your users do. For a walkthrough of reading the built-in graphs, see the Graphs guide, and check System Metrics for the host-level CPU, memory, disk, and network series that sit alongside these NGINX counters.