Server Monitoring Basics: What to Measure and Why

Most teams start server monitoring by watching CPU and memory, then wonder why they still get paged for incidents those graphs never predicted. The metrics that actually correlate with user-facing problems are availability, latency percentiles, error rate, and saturation - plus two signals teams routinely forget: certificate and domain expiry.

The Four Signals That Matter Most

Two well-known frameworks converge on the same core metrics from different angles.

USE method (for resources: CPU, memory, disk, network):

• Utilization - percentage of time the resource is busy
• Saturation - amount of queued work the resource can't service
• Errors - count of error events

RED method (for services/requests):

• Rate - requests per second
• Errors - failed requests per second
• Duration - latency distribution

Together, these tell you both how the system is running (USE) and whether the service is actually usable (RED). Availability, covered separately below, is the outcome you're ultimately trying to protect.

Availability: The Metric That Matters to Users

Availability is the percentage of time a service is reachable and functioning within acceptable parameters - not just "server is up."

availability = (total_checks - failed_checks) / total_checks * 100

Measure this from outside your infrastructure, not from internal logs alone - a service can look "up" to itself while being unreachable due to DNS, network, or CDN issues. This is exactly what external uptime monitoring is for.

Latency Percentiles: Why Averages Lie

Average latency hides the experience of your slowest users. If 95% of requests take 50ms and 5% take 5 seconds, the average might look like a perfectly reasonable 300ms - while 1 in 20 users has a terrible experience.

• p50 (median) - typical experience
• p95 - the threshold 95% of requests fall under; a good proxy for "acceptable but not great"
• p99 - tail latency; often reveals GC pauses, lock contention, or downstream timeouts

curl -s -o /dev/null -w "%{time_total}\n" https://api.example.com/v1/orders

Run this repeatedly and compute percentiles, or better, use a monitoring tool that tracks percentile trends over time so you can catch gradual regressions before they become incidents.

for i in $(seq 1 50); do
  curl -s -o /dev/null -w "%{time_total}\n" https://api.example.com/v1/orders
done | sort -n | awk '{a[NR]=$1} END {print "p50:", a[int(NR*0.5)], "p95:", a[int(NR*0.95)], "p99:", a[int(NR*0.99)]}'

Set alert thresholds on p95 or p99, not on average latency - averages will stay flat while your worst-case experience deteriorates.

Error Rate: Distinguish Client vs Server Errors

Track error rate as a percentage of total requests, split by cause:

• Client errors (4xx) - often expected, but a spike can indicate a broken client release or deprecated API version still in use
• Server errors (5xx) - always worth investigating, should have a low, stable baseline

error_rate = failed_requests / total_requests * 100

A sudden jump in 5xx rate, even a small absolute number, is often the earliest signal of an incident - well before availability checks fail outright, since a service can return errors for a subset of requests while still answering health checks successfully.

Saturation: The Leading Indicator

Saturation measures how much queued demand a resource has beyond what it can currently serve - CPU run queue length, connection pool wait time, disk I/O queue depth. Saturation typically rises before latency and error rate visibly degrade, making it a leading indicator rather than a lagging one.

Common saturation signals to track:

• Database connection pool: active vs max connections
• Thread/worker pool: queued tasks waiting for a worker
• Message queue: consumer lag
• Disk: I/O wait time

Certificate and Domain Expiry as Monitoring Signals

These aren't traditionally grouped with "performance" metrics, but an expired TLS certificate or domain registration causes a full, sudden outage indistinguishable from a server crash - and it's entirely preventable with monitoring.

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

whois example.com | grep -i "expir"

Treat these as first-class monitoring signals:

• Alert 30, 14, and 7 days before certificate expiry
• Alert 30 and 7 days before domain registration expiry
• Include certificate chain validity, not just the leaf certificate's expiry date

SSL monitoring and domain expiration monitoring close a gap that pure performance metrics never catch - the service can be perfectly healthy by every other measure and still go fully offline the moment a cert or domain lapses.

Bringing It Together: A Minimal Monitoring Checklist

• External availability checks from multiple regions
• Latency tracked as p50/p95/p99, not just average
• Error rate split by 4xx vs 5xx, alerting on 5xx spikes
• Saturation metrics on connection pools, queues, and worker capacity
• TLS certificate expiry monitored with advance warning
• Domain registration expiry monitored with advance warning
• A public status page so users and stakeholders see incidents without asking support

Platforms like ServerInspector combine availability, latency percentile, SSL, and domain expiry checks into one dashboard, which avoids the common failure mode of having five different tools each covering one signal and nobody actually looking at all five.

FAQ

Why is p95 latency more useful than average latency?

Average latency is skewed low by the bulk of fast requests and hides tail behavior. p95 and p99 reveal what your slower users actually experience, which is usually where real complaints and support tickets originate.

What's the difference between the USE and RED methods?

USE (Utilization, Saturation, Errors) is designed for monitoring resources like CPU and disk. RED (Rate, Errors, Duration) is designed for monitoring request-driven services. Most production systems benefit from tracking both.

How far in advance should I get alerted about SSL certificate expiry?

30 days gives enough lead time for renewal and deployment, with follow-up alerts at 14 and 7 days as a safety net in case the first alert is missed or renewal is delayed.

Is 99.9% uptime good enough?

It depends on the business impact of ~43 minutes of downtime per month. For consumer-facing services this is often acceptable; for payment or infrastructure APIs, teams typically target 99.95% or higher.

Should saturation metrics trigger the same alert severity as error rate?

Not necessarily immediately - saturation is a leading indicator. Treat rising saturation as a warning to investigate before it becomes an outage, and reserve page-level severity for when it actually translates into elevated errors or latency.