Your uptime dashboard shows 99.9% availability. Everything looks healthy. Then customer complaints start arriving about slow responses, timeout errors, and missing data.
The service was available. It was not reliable.
Reliability metrics reveal what availability alone cannot: whether your service performs correctly, responds quickly, and handles edge cases gracefully. Understanding which metrics to track and what they indicate helps teams build services users trust.
What Makes a Metric a Reliability Metric
Reliability metrics measure correctness and consistency, not just presence. A service is reliable when it responds correctly within expected time bounds for the vast majority of requests over time.
Availability answers: “Is the service responding?” Reliability answers: “Is it responding correctly, quickly, and consistently?”
This distinction matters because a service can be available while being completely unreliable. An API that returns 500 errors for half of all requests is technically available but unusable. A database that occasionally returns stale data is online but untrustworthy.
The metrics that reveal reliability fall into several categories.
Availability Metrics
Availability measures the percentage of time a service is operational and responding to requests. It is the foundational reliability metric because a service that is down cannot be reliable by any other measure.
Uptime percentage is the most common availability metric. A service with 99.9% availability experiences about 8.7 hours of downtime per year. At 99.99%, that drops to 52 minutes per year.
The numbers sound similar but the operational difference is significant:
- 99% availability = 3.65 days of downtime per year
- 99.9% availability = 8.76 hours per year
- 99.99% availability = 52.6 minutes per year
- 99.999% availability = 5.26 minutes per year
What availability reveals: Infrastructure stability, deployment quality, and capacity planning effectiveness. Frequent downtime usually indicates operational process problems rather than code bugs.
What availability hides: Performance degradation, error rates, and user experience problems. A service can be up while being too slow or too error-prone to use effectively.
Error Rate Metrics
Error rate measures the proportion of requests that fail versus succeed. This is often expressed as a percentage or as errors per thousand requests.
The calculation is straightforward: failed requests divided by total requests, multiplied by 100 for percentage.
Error rates below 0.1% are typical for healthy production services. Rates above 1% usually indicate significant problems requiring investigation.
Different error types carry different severity:
- Client errors (4xx): Often expected behavior from invalid requests
- Server errors (5xx): Usually indicates bugs or infrastructure problems
- Timeout errors: Suggests capacity or dependency issues
Tracking error rates by endpoint reveals which parts of your service need attention. A checkout API with 2% errors matters more than an internal health check with occasional failures.
What error rates reveal: Code quality, edge case handling, and integration reliability. Rising error rates often precede outages.
What error rates hide: The user impact of errors. A 1% error rate means different things for a page with 100 daily visitors versus 10 million.
Latency Metrics
Latency measures how long requests take to complete. Fast responses indicate healthy systems. Slow responses indicate resource constraints, inefficient code, or dependency problems.
Average latency is misleading because outliers get hidden. A service with 50ms average latency might have 10% of requests taking over 2 seconds, making it feel slow to many users.
Percentile metrics reveal the full picture:
- P50 (median): The response time that half of requests beat
- P95: The response time that 95% of requests beat
- P99: The response time that 99% of requests beat
The gap between P50 and P99 reveals consistency. A service with P50 of 50ms and P99 of 5000ms has serious reliability problems that average latency would hide.
Different latency phases provide debugging context:
- DNS resolution time
- TCP connection time
- TLS handshake time
- Time to first byte
- Total response time
Tracking each phase separately helps identify whether slow responses come from network issues, server processing, or external dependencies.
What latency reveals: Resource constraints, inefficient queries, slow dependencies, and capacity limits.
What latency hides: Errors (fast failures look good in latency metrics) and intermittent problems that recover before measurement.
Success Rate Metrics
Success rate inverts error rate to measure what percentage of requests succeed. While mathematically equivalent, success rate frames reliability positively and aligns with SLO language.
A 99.9% success rate means 1 in 1,000 requests fails. This framing makes targets intuitive: you want success rate as close to 100% as your architecture and budget allow.
Success rate works well as a Service Level Indicator because it directly reflects user experience. Users experience successes and failures, not error rates.
Composite success rates consider multiple criteria:
- Request completed without error
- Response time within acceptable bounds
- Response content passed validation
A request might return 200 OK but take 30 seconds, effectively failing from the user perspective. Composite metrics capture this nuance.
Throughput Metrics
Throughput measures how many requests your service handles per unit of time. This indicates both capacity and demand.
Requests per second (RPS) is the common unit. Tracking throughput over time reveals usage patterns: peak hours, seasonal variations, and growth trends.
Throughput itself is not a reliability metric, but changes in throughput patterns often predict reliability problems. Sudden throughput drops might indicate upstream failures. Throughput approaching capacity limits predicts latency increases.
Saturation metrics complement throughput. Saturation measures how close you are to capacity limits:
- CPU utilization approaching 100%
- Memory usage near limits
- Connection pool exhaustion
- Queue depth increasing
High saturation with stable throughput suggests impending performance degradation. The service is working hard to maintain current load and has no headroom for traffic spikes.
Measuring Reliability Over Time
Single measurements provide snapshots. Reliability requires measuring over meaningful time windows.
Daily aggregations reveal operational patterns but miss short outages. A 15-minute outage in a 24-hour window might not significantly impact daily availability calculations.
Weekly trends show whether reliability is improving or degrading. Comparing this week to last week reveals the impact of recent changes.
Monthly reports align with business reporting cycles and SLA commitments. Many contracts specify monthly availability targets.
Rolling windows (last 7 days, last 30 days) provide current state without calendar boundary effects.
Pre-aggregated metrics enable fast queries across time ranges. Calculating reliability from raw data at query time does not scale for services handling millions of daily requests.
From Metrics to Decisions
Metrics have value only when they inform action. Different reliability metrics suggest different responses.
Availability problems usually require infrastructure or operational process improvements. Frequent outages suggest deployment problems, capacity issues, or inadequate redundancy.
Error rate problems typically indicate code bugs, integration failures, or missing edge case handling. Rising error rates after deployments point to recent changes.
Latency problems often stem from resource constraints, inefficient algorithms, or slow dependencies. Latency that increases with load suggests capacity limits.
Throughput problems may indicate capacity needs, upstream failures, or changed usage patterns. Sudden throughput drops warrant immediate investigation.
Tracking multiple metrics together reveals patterns that single metrics miss. Latency increasing while throughput stays constant suggests resource exhaustion. Error rates rising with throughput indicates load-related failures.
Setting Reliability Targets
Raw metrics become actionable through targets. Service Level Objectives define acceptable reliability levels.
Choosing targets requires balancing user expectations, engineering cost, and business requirements. Higher reliability costs more to achieve and maintain.
Start with measurements of current performance. If your service currently achieves 99.5% availability, targeting 99.99% requires significant investment. Targeting 99.9% might be achievable with moderate improvements.
Different services warrant different targets. A payment processing API needs higher reliability than an internal reporting dashboard. User-facing services need lower latency than batch processing systems.
Error budgets make targets operationally useful. If your SLO is 99.9% availability, you have 0.1% error budget. This budget can fund risky deployments, maintenance windows, and experiments. When the budget depletes, you prioritize reliability work.
How Teams Use Reliability Metrics
Upstat provides reliability tracking through integrated monitoring and reporting. Multi-region uptime checks measure availability from multiple geographic locations, revealing regional problems that single-location monitoring misses.
Response time tracking breaks down latency into phases: DNS resolution, TCP connection, TLS handshake, and time to first byte. This granularity helps identify whether slow responses come from network issues, certificate problems, or application processing.
Availability reports aggregate uptime data into daily trends and historical patterns. MTTR analysis shows how quickly incidents get resolved, revealing operational efficiency.
Pre-aggregated metrics enable fast dashboard loads and trend analysis without recalculating from raw data. This approach balances real-time accuracy with query performance.
Start With These Three
If you track nothing else, track these three reliability metrics:
- Availability percentage: The foundation that everything else builds on
- Error rate: The clearest signal of broken functionality
- P95 latency: The user experience that average latency hides
These three metrics catch most reliability problems and require minimal infrastructure to implement. As your reliability practice matures, add throughput tracking, composite success rates, and dependency health monitoring.
Reliability is not a destination but a practice. The metrics you track today reveal the improvements needed tomorrow. Start measuring, set targets, and iterate.
Explore In Upstat
Track reliability metrics with multi-region uptime monitoring, response time percentiles, availability reports, and MTTR analysis that reveal service health trends.