Follow the request rate
See requests per second from Nginx counters. A first sample, counter reset or missing comparison sample leaves a gap instead of inventing zero traffic or a sudden spike.
Your web server, in view.
From requests to connections.
Monitor Nginx requests, active connections and connection states. Set thresholds, detect missing metrics and follow recovery in your Upty workspace.
Part of your Upty workspace · One workspace. Every signal.
REQUESTS PER SECOND184 req/s
- Web server
- Nginx
- Requests per second
- 184 req/s
- Active connections
- 62
- Collector
- Receiving metrics
A successful HTTP response is one part of web server health. A Webserver monitor brings the Nginx metrics behind it into your workspace: request rate, active connections and the connections currently reading, writing or waiting.
An OpenTelemetry Collector on your server reads a private Nginx stub_status endpoint and sends supported metrics to Upty over HTTPS. Each monitor has its own ingestion token. The status endpoint stays local; it does not need to be exposed to public monitoring probes.
Set optional thresholds for active connections and requests per second, then choose an evaluation window and alert destinations. Missing metrics have their own signal, so a stopped collector is not displayed as a quiet server with zero traffic. Add a separate Website, Host or SSL monitor when you also need availability, machine resources or certificate health.
Keep this signal alongside the rest of your stack: organize related services, choose who receives alerts and follow recovery in the same workspace. The goal is a check that explains what changed and gives the right person a useful place to start.
SMALL DETAILS. USEFUL CONTEXT.More than
More than
an up or down.
Purpose-built checks.
Information you can act on.
See connection states
Track active connections alongside reading, writing and waiting connections. These signals help you distinguish request activity from idle keep-alive connections.
Set focused thresholds
Enable an active-connection or request-rate threshold when it is useful for your service. Choose an evaluation window to require sustained pressure instead of alerting on every brief burst.
Notice when data stops
A new monitor waits for its first metrics and warms up before threshold evaluation. Once connected, a collector that stops reporting can make the monitor down and trigger your configured alerts.
Keep the status endpoint private
The Collector reads Nginx locally or through a private network. Its separate ingestion token only sends metrics for one monitor; it does not grant access to the workspace or the server.
Keep related signals together
Use the same groups, alert destinations and monitor history as your other checks. Add external HTTP checks for the visitor-facing response and Host monitoring for CPU, memory and disk context.
WHERE IT FITSMade for the work
Made for the work
you already do.
One reliable signal.
Plenty of practical uses.
Production Nginx servers
Follow traffic and connection trends on a web server or reverse proxy. Give each instance its own monitor and token so the charts and thresholds describe that specific server.
Traffic changes and deployments
Review request rates and connection states after a release or a traffic change. Compare the internal metrics with a separate Website monitor before deciding where to investigate.
Teams with an existing Collector
Keep your current host metrics pipeline and add a separate webserver receiver, exporter and pipeline. A dedicated Collector service or Docker container is also available when you prefer an independent configuration.
FROM SETUP TO A USEFUL SIGNALStart with what
Start with what
matters most.
Use a meaningful name, choose the behavior you expect and make sure the alert reaches someone who can act. Start with one service, then add the related checks as your monitoring grows.
Open the setup guide- 01
Choose your starting point.
Create a monitor and select Webserver (Nginx). Enter a recognizable name and the private stub_status endpoint that the Collector will read. Choose an evaluation window and any optional thresholds.
- 02
Configure the check.
Copy the Nginx status snippet and the generated Linux or Docker Collector configuration. Keep the endpoint private and save the one-time token securely. Existing Host monitoring uses a different token and pipeline.
- 03
Follow the signal.
Start the Collector, confirm that metrics arrive and let the initial evaluation window fill. Open the monitor to follow request rate, connections, history and alerts. Rotate the token from the connection settings when needed.
A LITTLE MORE CONTEXTGood questions.
Good questions.
Clear answers.
The details that help you choose the right check and get a useful result.
Read the full documentationWhat does the Webserver monitor measure?+
The first version supports Nginx through its stub_status endpoint. It charts requests per second, active connections and reading, writing and waiting connections, with optional thresholds for request rate and active connections.
Does it support Apache or IIS?+
This Webserver monitor currently supports Nginx only. Website and API monitors can still check HTTP endpoints served by Apache, IIS or another web server, but their internal web server metrics are not collected by this integration.
Do I need to expose nginx_status to the internet?+
No. The Collector reads the status endpoint on your server or private network and sends metrics out to Upty over HTTPS. The supplied Nginx snippet listens on loopback. Keep that endpoint private.
Can I keep my existing Host Collector?+
Yes. Keep its configuration and host token unchanged. Merge the webserver receiver, its own exporter and its dedicated pipeline into the existing Collector carefully, or run the supplied separate service or Docker container.
Does it measure 5xx errors or every visitor request latency?+
No. The basic Nginx status endpoint provides traffic counters and connection states. Aggregate HTTP error rates and request latency need additional access-log processing or instrumentation. Use Website and API monitors separately to check the response seen by monitoring probes.
What happens when metrics stop arriving?+
A never-connected monitor stays pending. After fresh metrics arrive and the initial evaluation window fills, a window with no data can make the monitor down. The monitoring backend evaluates missing data, so ingestion and minute-based evaluation can delay the visible status change.
Which plans include Webserver monitoring?+
Webserver monitoring is included in the standard Free, Pro and Business plans and uses one ordinary monitor slot. It has no probe-region selection; the Collector sends metrics about every 30 seconds and the monitor evaluates them every minute. API and MCP access remain separate plan features.
LESS CHECKING. MORE KNOWING.One more thing
Get started One more thing
off your mind.
Bring webserver monitoring into your workspace.