Server performance metrics are the measurable data points that indicate whether a server is healthy, under stress, or heading toward failure. The key categories are CPU, memory, disk, network, process and hardware health, and availability; each capturing a different dimension of server health. Monitoring all six gives IT teams a clearer picture of server health and helps catch issues before they turn into outages.
Most server performance issues don’t happen overnight. They often show up as gradual changes in the numbers: CPU usage slowly increasing, disk space steadily filling up, or response times getting worse as memory pressure builds. These metrics can help you spot those warning signs early, while there’s still time to fix the problem.
For each metric, this guide covers how it’s calculated, what normal looks like, suggested starting thresholds, why it matters, and what you risk missing if you don’t monitor it.
A note on the thresholds in this guide:
- Use these as starting points: Warning and critical values are guidelines, not universal rules.
- Consider workload: A database server that runs at 75% CPU during scheduled batch jobs is behaving normally. A web server unexpectedly hitting 75% is not. Same number, different meaning.
- Baseline before fine-tuning: Use these values for initial alerts, then recalibrate after 4—6 weeks of performance data from your specific environment.
- Set thresholds to fit the server: The right threshold depends on each server's normal behavior; general-purpose servers, database servers, file servers, and batch processing servers all have different baselines.
- Some thresholds are universal: Swap usage, packet loss, S.M.A.R.T. errors, RAID degradation, and hardware event log warnings are always a problem regardless of server type. No recalibration needed for these.
The threshold column headers in each table reflect this: they are starting points to adjust, not fixed targets to apply universally.
CPU metrics
CPU metrics measure how much processing demand is being placed on a server's processor, and whether that demand is sustainable or heading toward saturation.
| Metric | What it means | Normal range | Suggested warning (adjust to baseline) | Suggested critical (adjust to baseline) | Why it matters |
|---|---|---|---|---|---|
| CPU utilisation (%) | The percentage of total processor capacity the server is actively using at a given moment | 20—70% during business hours | > 70% sustained for 5+ min | > 85% sustained for 5+ min | Sustained high CPU degrades application response times and causes request queuing, timeouts, and crashes |
| CPU load average (1 min) | The average number of processes waiting for or using the CPU over the last minute | ≤ number of CPU cores | > number of cores | > 2× number of cores | Load average above core count means work is queuing, the server cannot keep up with demand. |
| CPU I/O wait (%) | The percentage of time the CPU is idle because it is waiting for a disk or network operation to complete. | < 5% | > 10% sustained | > 20% sustained | High I/O wait means the CPU is not the bottleneck, disk or network is. Fixing CPU allocation will not resolve performance issues when I/O wait is the root cause. |
| CPU steal time (%) | On virtual machines: the percentage of time the vCPU is waiting for a physical CPU being used by another VM on the same host | < 5% | > 10% | > 20% | Steal time indicates host-level CPU contention; the VM is being starved by competing workloads, causing degradation that standard CPU utilization metrics will not show. |
What to watch for: CPU utilization is important, but it may not reveal a performance issue early. I/O wait and load average can expose bottlenecks sooner, while CPU steal time on virtual machines can explain performance degradation that overall CPU usage may not show. The 70% warning threshold is a general starting point; database and batch servers may normally run higher and should be tuned to their baseline.
Memory metrics
Memory metrics measure RAM consumption and whether the server is beginning to use slower storage as a substitute for physical memory, a state that significantly degrades performance.
| Metric | What it means | Normal range | Suggested warning (adjust to baseline) | Suggested critical (adjust to baseline) | Why it matters |
|---|---|---|---|---|---|
| Memory utilisation (%) | The percentage of total RAM currently in use by the OS and running processes. | < 75% | > 75% sustained | > 90% sustained | When memory is nearly full, the OS uses disk space as temporary memory, which can significantly slow down the server. |
| Available memory (GB) | The absolute amount of RAM not currently allocated to any process. | Environment-dependent; establish per server. | < 20% of total RAM | < 10% of total RAM | When available memory drops to this level, application instability and crash risk increase significantly. |
| Page file / swap usage (%) | The percentage of the virtual memory file (Windows) or swap partition (Linux) currently in use | < 5% | > 10% | > 25% | Meaningful swap activity indicates that physical RAM is under pressure and the OS is relying on disk instead, which can significantly slow down the server. As a general rule, swap usage should be investigated regardless of the server type. |
| Memory page faults/sec | The rate at which the OS must retrieve memory pages from disk because they are no longer in RAM (hard faults only) | Hard faults near zero | Hard faults > 10/sec | Hard faults > 50/sec | Each hard page fault requires the OS to read data from disk, adding latency to affected operations. A high hard-fault rate is a strong sign of active memory pressure. |
What to watch for: Focus on available memory and swap usage rather than memory utilization alone. A server using 88% of its memory with no swap activity is in a much better state than one using 15% swap at the same utilization level. Unlike CPU thresholds, swap activity is a strong warning sign across server types. Meaningful swap usage during active workloads usually indicates memory pressure and should be investigated promptly.
Disk metrics
Disk metrics cover two distinct concerns: capacity (will the disk fill up?) and performance (is the disk fast enough?). Both matter, and both can cause outages, but through entirely different failure modes.
| Metric | What it means | Normal range | Suggested warning (adjust to baseline) | Suggested critical (adjust to baseline) | Why it matters |
|---|---|---|---|---|---|
| Disk space used (%) | The percentage of total storage capacity currently occupied by data, applications, and logs. | < 70% | > 75% | > 90% | A full disk prevents applications from writing logs, completing database transactions, or creating temp files; causing crashes and potential data loss. |
| Disk I/O utilization (%) | The percentage of time the disk is actively processing read or write requests. | < 50% sustained | > 70% sustained | > 90% sustained | When the disk is constantly busy, new requests queue behind it increasing latency for every operation. High-throughput storage servers may have a higher normal baseline. |
| Disk queue depth | The number of read or write requests waiting for the disk to become available at any given moment. | < 1 | > 2 sustained | > 5 sustained | A queue depth above 1 means disk requests are waiting to be processed, increasing latency for applications using that disk. |
| Disk read/write latency (ms) | The time taken to complete a single read or write operation from the moment it is requested. | < 5ms (SSD), < 20ms (HDD) | > 10ms (SSD), > 50ms (HDD) | > 25ms (SSD), > 100ms (HDD) | Latency is felt directly by applications and users. Slow disk latency on a database server shows up as slow queries, not as a storage alert |
| Disk growth rate (GB/month) | The average amount of additional storage consumed per month, based on historical trend data | Varies; establish per volume. | When projected time to 85% < 90 days | When projected time to 85% < 30 days | The most important disk metric for avoiding capacity outages; it tells you when you will run out, not just how full you are now. |
What to watch for: Disk latency is often overlooked, even though it can reveal problems before disk capacity does. A database server may have plenty of free space but still experience rising I/O latency, leading to slow queries and timeouts that can look like application issues. Disk space thresholds of 75% or 90% are useful general starting points, while I/O utilization thresholds should be adjusted for servers with consistently high workloads, such as database and storage servers.
Note: The disk space and I/O metrics above measure current state; the disk growth rate metric measures trajectory. Both can be critical simultaneously; a disk at 68% utilization that's filling at 5 GB/month may be a higher priority than one at 79% utilization with flat growth.
Network metrics
Network metrics measure the flow of data into and out of the server. Saturation, errors, and packet loss each cause different failure modes that other metric categories will not detect.
| Metric | What it means | Normal range | Suggested warning (adjust to baseline) | Suggested critical (adjust to baseline) | Why it matters |
|---|---|---|---|---|---|
| Network interface utilization (%) | The percentage of the network interface's total capacity currently used for inbound and outbound traffic combined. | < 50% sustained | > 60% sustained | > 80% sustained | A saturated interface queues traffic; all applications and users on that server experience latency simultaneously. |
| Packet loss rate (%) | The percentage of data packets sent that fail to reach their destination. | 0% | > 0.1% | > 1% | Even small amounts of packet loss can cause TCP retransmissions and increase latency. Sustained packet loss is a warning sign and should be investigated regardless of the server role. |
| Network error rate | The number of transmission errors per second reported by the network interface. | 0 | > 0 (any sustained errors) | > 10 errors/sec | Interface errors indicate hardware issues, duplex mismatch, or cabling problems; persistent errors precede full interface failure. |
| Bytes in / bytes out (Mbps) | The actual volume of data flowing into and out of the server per second. | Varies by role; establish per server. | > 60% of provisioned bandwidth | > 80% of provisioned bandwidth | Sudden changes in traffic volume in either direction can indicate a workload spike, a misconfiguration, or a security event. |
What to watch for: Packet loss and network errors are strong warning signs regardless of the server or workload. Sustained packet loss or interface errors should always be investigated. However, network utilization thresholds depend on the workload, so servers handling heavy traffic, such as file or backup servers, may normally run above 60%.
Process and hardware health metrics
Process and hardware health metrics provide visibility into problems that CPU, memory, disk, and network metrics can miss. They can reveal issues such as a runaway process consuming resources, a disk developing bad sectors, or a server overheating before performance starts to degrade.
These metrics can be collected through SNMP, WMI, IPMI, and S.M.A.R.T., without requiring application-level instrumentation.
| Metric | What it means | Normal range | Suggested warning (adjust to baseline) | Suggested critical (adjust to baseline) | Why it matters |
|---|---|---|---|---|---|
| Process count | The total number of active processes running on the OS at a given moment. | Establish per server; a stable count is normal | > 20% above established baseline | > 50% above established baseline | A sudden increase in process count can indicate a runaway application or security issue before CPU or memory usage rises noticeably. |
| Process CPU consumption | The percentage of total CPU being consumed by a single process or the top N processes. | Environment-dependent | Any single process > 40% CPU sustained | Any single process > 70% CPU sustained | Server-level CPU utilization tells you the server is under load; process-level monitoring tells you which process is responsible. Essential for root cause diagnosis. |
| CPU temperature | The physical temperature of the processor as reported by onboard sensors | < 70°C under load | > 80°C | > 90°C | Sustained high temperature throttles the processor and causes long-term hardware damage. A server can run at normal CPU utilization while overheating due to a failed fan or blocked airflow. |
| Hardware event log (IPMI / iDRAC / iLO) | Events recorded by the server's baseboard management controller: fan failures, power supply faults, memory errors, temperature warnings. | No active events | Any warning-level hardware event | Any critical hardware event or memory ECC error | Hardware failures can show up here before they affect OS performance. A failing power supply or memory module may generate hardware alerts before the server crashes. Any hardware alert should be investigated. |
| S.M.A.R.T. disk health | The self-reported health status of each physical disk, including reallocated sectors, pending sectors, and uncorrectable read errors. | All attributes within vendor normal range | Any increase in reallocated sector count | Pending sectors > 0 or uncorrectable errors > 0 | Predicts disk failure before performance drops. Rising reallocated sectors are a warning sign, even when disk capacity and latency look normal. |
| RAID / storage array status | The operational state of the storage array: optimal, degraded, rebuilding, or failed. | Optimal | Degraded (one drive failed, array still running on redundancy) | Failed or rebuilding after a second failure | A degraded RAID is at risk of data loss if another disk fails. Without monitoring, the problem may only be noticed after the second disk fails when it’s already too late. |
What to watch for: Hardware health is often overlooked because it requires access to IPMI or S.M.A.R.T. data, which many monitoring setups don’t enable by default. Unlike performance thresholds, hardware alerts are generally not workload-dependent. A hardware warning or rising reallocated sector count should be investigated regardless of the server type or workload.
Service health metrics
Service and process health metrics catch issues that CPU, memory, and other performance metrics can miss. A server may appear healthy while a critical service is stopped, repeatedly restarting, or has recently crashed. These metrics help track the health and stability of critical services and processes.| Metric | What it means | Normal range | Suggested warning (adjust to baseline) | Suggested critical (adjust to baseline) | Why it matters |
|---|---|---|---|---|---|
| Critical service status | Whether a defined critical service, such as IIS, SQL Server, Apache, Active Directory, or Exchange, is running, stopped, or restarting. | Up | Restarting or repeated restarts | Down for >N minutes | A server can have normal CPU and memory usage while a critical service has been down for 20 minutes. Service monitoring catches what performance metrics can miss. |
| Service restart count (per 24h) | The number of times a specific service has restarted in the last 24 hours. | 0 restarts | >2 restarts | >5 restarts | Automatic restart policies can hide service instability. A service may appear healthy because it is currently running, while frequent restarts reveal an underlying problem. |
| Process uptime | How long a critical process has been running since its last start. | Consistent with the expected process lifecycle | Unexpectedly low uptime or recent restart | Repeated unexpected restarts | A web server process that restarted four minutes ago on a server that has been running for six hours may indicate a recent crash or failure. It adds context to restart monitoring, especially for processes without explicit service monitoring. |
What to watch for: A service showing as "running" doesn't always mean it's healthy. Frequent restarts or unexpectedly short process uptime can reveal instability that a simple status check may miss. Monitor critical services and processes based on their expected behavior, and investigate repeated restarts rather than treating each automatic recovery as a normal event.
Availability metrics
Availability metrics measure not just whether a server is running, but how reliably it runs over time and how quickly problems are resolved when they occur.
| Metric | What it means | Normal range | Suggested warning (adjust to baseline) | Suggested critical (adjust to baseline) | Why it matters |
|---|---|---|---|---|---|
| Uptime (%) | The percentage of total time a server has been available and operational over a defined period. | 99.9%+ for production servers | < 99.9% over rolling 30 days | < 99% over rolling 30 days | Maps directly to SLA commitments and quantifies the business cost of every unplanned outage |
| Mean Time Between Failures (MTBF) | The average time a server runs between one failure and the next, a measure of reliability | Varies; higher is always better | Declining trend over 3 months | MTBF below your SLA-implied minimum | A declining MTBF means failures are becoming more frequent; a trend that uptime percentage alone may not surface until it is already significant. |
| Mean Time To Repair (MTTR) | The average time from the moment a failure occurs to full service restoration, a measure of recoverability. | < 1 hour for critical servers | > 2 hours for critical servers | > 4 hours for critical servers | MTTR includes detection, response, diagnosis, and repair time. Reducing any one of these improves availability even if failures occur at the same rate. |
| Server response time (ms) | The time the server takes to respond to a request, a measure of whether it is not just running, but functioning adequately. | < 200ms for internal services | > 500ms sustained | > 1,000ms sustained | A server can be technically up while responding too slowly for applications to function. Response time connects infrastructure health to what users actually experience. |
What to watch for: Look at uptime and MTBF trends over 90 days, rather than judging reliability from a single incident. One bad month may be an exception, but a steady drop in MTBF over several months can signal a deeper reliability issue. Also track server response time, since a server can be online but still respond too slowly for applications to function properly.
MTBF and MTTR: the availability equation
Unlike the performance metrics above, MTBF and MTTR measure the outcome of failures, rather than the server’s current health. They help you understand whether your monitoring strategy is actually reducing downtime or simply reporting failures after they happen.
Availability (%) = MTBF ÷ (MTBF + MTTR) × 100
For example, a server with 6 failures over 90 days and 4 total hours of downtime has an MTBF of 359 hours and an MTTR of 1.33 hours, resulting in approximately 99.6% availability.
There are two ways to improve availability:
- Increase MTBF: Reduce how often failures occur through proactive monitoring, better hardware, and stronger change management.
- Reduce MTTR: Detect and resolve failures faster with timely alerts, clear runbooks, and effective on-call processes.
For servers with frequent incidents, reducing MTTR can deliver faster improvements. Monitoring plays a key role because the sooner a failure is detected, the sooner the team can start fixing it.
How do you use server performance metrics together?
No single metric tells the full story. A server can have normal CPU and memory usage while a critical service has stopped, disk space is rapidly declining, or packet loss is affecting users.
Looking at these metrics together helps you spot both current problems and early warning signs before they become outages.
Monitor all of these metrics automatically with ManageEngine OpManager
Tracking multiple metrics manually across dozens or hundreds of servers isn’t practical. OpManager automates this process, monitoring CPU, memory, disk, network, processes, hardware health, and availability across physical and virtual servers, Windows, Linux, VMware, Hyper-V, and cloud environments from a single console.
OpManager covers the full infrastructure monitoring stack out of the box:
- CPU, memory, disk, and network: Collected via SNMP and WMI across Windows and Linux servers, with pre-built dashboards, top-N reports, and historical trend graphs per device
- Service and process monitoring: 70+ critical services monitored out of the box including IIS, SQL Server, Exchange, DNS, Active Directory, and VMware, with configurable auto-restart for transient failures
- Hardware health: SNMP and IPMI monitoring for Dell, HP, IBM, and Lenovo servers, covering hardware event logs, temperature, fan status, power supply health, and RAID array status
- Availability and response time: Uptime tracking, availability reports, MTTR and MTBF data from alarm history, and response time monitoring per device.
- Capacity forecasting: Disk growth rate analysis and resource utilization trend reports predicting when each metric will reach 80%, 90%, and 100%, with a projected date per device.
- Adaptive thresholds: AIOps-powered threshold adjustment that learns each server's normal behavior, so alerts reflect your environment's actual baseline rather than generic starting points.
FAQs on server performance metrics
What are the most important server performance metrics to monitor?
The key metrics are CPU utilization, memory and swap usage, disk space and latency, network utilization and packet loss, and server uptime. Together, they show whether a server has enough resources, is performing efficiently, and is available when users need it.