Four signals are a starting point, not a checklist.
Choose indicators that describe actual user impact, and establish their limits before alerting.
A request can finish but still fail
Availability should follow the outcome promised to the client. HTTP 200 alone may not indicate a usable operation. Consider the result of an entire transaction, retries and partial successes. Write down exactly what constitutes success.
Measure distributions, not just averages
An average hides slow experiences. Percentiles help describe the tail of a latency distribution, but only when sample sizes and time windows are appropriate. Report the population and denominator.
Count meaningful failures
Distinguish service-side errors from validation failures or deliberate client cancellations. A good error ratio uses consistently classified requests and explains excluded traffic.
Know when there is no headroom
Queue growth, blocked workers and pool exhaustion can signal future trouble. Use them to interpret symptoms or protect capacity, rather than paging on every momentary rise.
Make thresholds testable
A service-level objective (SLO) is a documented reliability target. If your target is 99.9% success, the corresponding error budget is 0.1% of eligible requests over the chosen period.
Calculate a sample budget →