Dashboards often begin with what infrastructure makes easy to count: CPU, memory, requests, and error logs. Those signals matter, but they do not tell an organisation whether a customer completed the journey, an operator received the approval, or a manager obtained a trustworthy report.
Useful measurement connects technical health to service performance and then to the intended outcome. The exact measures differ by product, but the structure should remain understandable to engineering, operations, and leadership.
Three layers of evidence
- Technical: availability, latency, correctness, errors, queue delay, and recovery time.
- Operational: completion time, waiting time, exception rate, rework, backlog, and handoff delay.
- Outcome: the business, social, or environmental result the service is expected to improve.
Use metrics to make decisions
Each measure should have an owner, a definition, a review cadence, and a decision it can influence. If a dashboard cannot change a priority, reveal a risk, or guide an improvement, it may be reporting activity rather than creating insight.
“Measure the experience people receive, the operation that delivers it, and the outcome that justifies it.”
— Renovative Lab principle
Reference point
Google's Site Reliability Engineering guidance recommends defining service indicators and objectives in terms that matter to users. Reference: https://sre.google/sre-book/service-level-objectives/