Saturation describes how close a resource is to its limit, often shown as a queue length or percentage of capacity. It covers CPU, memory, disk I/O, network bandwidth, thread pools, and database connections.
Why it matters
Performance rarely degrades in a straight line. Systems feel fine at 60 percent utilization, then latency climbs sharply as a resource approaches full and requests start queuing. Saturation warns you before users see slow pages or errors, so it is a leading indicator while error rate is a lagging one.
Example
A web server has a pool of 50 database connections. Watching only CPU shows 30 percent, which looks healthy. But the pool graph tells another story:
pool in use: 50 / 50
requests waiting: 120
p95 latency: 4.1 s
The database is not slow; the application is saturated waiting for a connection. Useful saturation metrics include run queue length, swap usage, disk queue depth, and thread pool queue size. Alert on sustained values, such as above 80 percent for 10 minutes, rather than momentary spikes.
Common mistakes
- Looking only at average utilization, which hides short bursts that fill queues.
- Ignoring non-obvious resources: file descriptors, ephemeral ports, inode counts.
- Alerting at 100 percent, when it is already too late.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.