Ops Health Dashboard

Following the monitoring distinctions in Google’s SRE guidance, an ops health dashboard brings operational KPIs onto one page: fill rate, uptime, SLA compliance, response time and cost per unit. It helps an operator locate a problem when each tile names its population, measurement window and service target.

Build the view around an operational decision

An operator needs to know what is failing now, who is affected, whether the evidence is current, and where to investigate. A weekly service review needs trends, recurring causes, and improvement priorities. Those purposes can share underlying data without sharing every tile. Start with a small set of indicators tied to outcomes, then provide diagnostic detail behind them; a page of every available metric makes the important change harder to find.

Each measure needs an eligible population, numerator and denominator where applicable, time window, target, and data source. Show the last successful update and missing-data state. Zero errors with zero observed requests is not evidence of healthy service. A stalled data feed should appear as unknown or stale rather than inheriting the last green status. An owner and a link to underlying records make a failed tile actionable.

Why one health score can hide a failure

If several indicators are combined, first specify how their units become comparable scores. Response time in milliseconds, a defect fraction, and a satisfaction score cannot simply be averaged. Scaling and weighting encode priorities; they do not discover an objective universal measure of health.

Suppose eight already-normalized scores have equal weight. If one drops from 99.7 to 97.0 while the rest stay fixed, the composite drops only 2.7/8 = 0.3375 points. A critical target can be missed without a large headline change. Taking the minimum does not necessarily solve this: if another component remains at 72.5, the minimum does not move at all. Keep each indicator’s SLO visible and allow critical failures to show independently of a composite.

Expose who the aggregate represents

For an illustrative request-success metric, suppose one customer supplies 98% of eligible requests at 99.9% success and another supplies 2% at 97% success. The request-weighted aggregate is 0.98 × 99.9% + 0.02 × 97% = 99.842%. The equally weighted customer average is 98.45%, and the second customer’s own result is 97%. Each answers a different question. Display customer or region views when the obligation or impact is defined at that level.

A request-success fraction cannot be converted into downtime minutes simply by multiplying by calendar time: traffic need not be uniform and failures may affect only some requests. If the tile measures time availability, define eligible intervals and what counts as unavailable. Keep the measurement unit consistent from source records through the roll-up.

Show the statistic that answers the commitment

Consider 100 hypothetical support tickets: 95 receive a response in 10 minutes and five in 60 minutes. Mean response time is 12.5 minutes, yet 5% miss a 30-minute target. If the five slow responses double to 120 minutes, the mean rises to 15.5 while the miss rate remains 5%. The target-crossing rate and lateness severity reveal different consequences. The SLA breach rate needs the population and rule used by the actual commitment.

Alongside the reporting-window result, show a recent trend when an emerging problem could be hidden by earlier good performance. Relevant segments, sample counts, latency distributions, and incident annotations help explain whether a change reflects a new failure, a traffic-mix shift, or a measurement change. Preserve metric definitions across comparisons, and annotate intentional revisions.

Connect observation to response

A dashboard supports inspection; an alert actively routes a condition to an owner. Define which failures require immediate response, which create a ticket, and which belong in routine review. Link urgent symptoms to diagnostic views and a response procedure. More red tiles do not necessarily mean more independent failures, since a shared dependency may affect several measures.

Validate the dashboard against a known incident and a known data-collection failure. Confirm that the right population turns unhealthy, stale evidence is visible, and drill-down records reproduce the displayed result. An attractive summary is useful only if an operator can trace its claim and use it to make the intended decision.

References

• Google SRE: Monitoring Distributed Systems
• Google SRE: Service Level Objectives
• Numerical scenarios, chosen rates and simulations in this entry are illustrative calculations by the author, not measurements reported by these sources.