Skip to content

Dashboard Standards

Dashboards provide a visual representation of system health, performance and operational trends. They should help engineers quickly understand the current state of a service, identify potential issues and support effective incident response.

A dashboard should answer a specific operational question. It should not be a collection of every available metric or a replacement for proper investigation and analysis.

This document defines the standards expected for dashboards used within managed services, including design principles, content, ownership, maintenance and how dashboards support monitoring and alerting.

Dashboard Design Principles

Dashboards should be designed around the needs of the people using them.

A good dashboard should:

  • Provide immediate visibility of service health.
  • Highlight meaningful changes in system behaviour.
  • Support incident investigation.
  • Present information in a logical order.
  • Reduce the time required to understand an issue.

Dashboards should not:

  • Display metrics without a defined purpose.
  • Attempt to represent every aspect of a system.
  • Replace alerts for conditions requiring action.
  • Require specialist knowledge to interpret basic service health.

The most useful dashboards are focused on operational outcomes rather than implementation details.

Dashboard Types

Different dashboards serve different purposes. A single dashboard should not attempt to satisfy every use case.

Dashboard Type Purpose Typical Audience
Service Overview Dashboard Provides a high-level view of service health SRE teams, support teams, stakeholders
Operational Dashboard Supports day-to-day monitoring and incident response SRE engineers, operations teams
Application Dashboard Provides application-specific performance information Development teams, SRE teams
Infrastructure Dashboard Shows underlying platform health Infrastructure teams
Capacity Dashboard Shows resource usage and growth trends Engineering teams, service owners
Business Dashboard Shows business-impacting metrics Service owners, product teams

Service Overview Dashboards

Every critical service should have a service overview dashboard that provides a rapid understanding of current health.

The dashboard should focus on the golden signals:

Signal Example Metrics
Latency Request duration, response time percentiles
Traffic Requests per second, transactions processed
Errors Failed requests, unsuccessful transactions
Saturation Resource pressure, queue depth, capacity limits

A service overview dashboard should allow an engineer to quickly determine:

  • Is the service available?
  • Are users experiencing failures?
  • Is performance degraded?
  • Is the service approaching capacity limits?

Dashboard Layout

Dashboards should present information in an order that supports investigation.

A recommended layout is:

1. Service Health

The first section should show the current operational state.

Include:

  • Availability.
  • Error rate.
  • Latency.
  • Traffic volume.
  • Active alerts or incidents where applicable.

This allows engineers to identify whether the service is currently experiencing impact.

2. User Impact

The dashboard should show metrics that represent the experience of users.

Examples:

  • Failed transactions.
  • Failed requests.
  • Response time.
  • Business transaction success rates.

User-impacting metrics should take priority over infrastructure metrics.

3. Application Performance

This section should provide deeper technical information.

Examples:

  • Endpoint performance.
  • Application exceptions.
  • Dependency performance.
  • Queue processing times.
  • Background job status.

4. Infrastructure Health

Infrastructure metrics should provide supporting context.

Examples:

  • CPU utilisation.
  • Memory usage.
  • Storage capacity.
  • Network usage.
  • Instance or container health.

Infrastructure metrics should help explain issues but should not be the only indicator of service health.

Dashboards should include relevant historical views to identify changes over time.

Examples:

  • Error rate trends.
  • Performance degradation.
  • Capacity growth.
  • Traffic changes.

Historical trends help distinguish between normal behaviour and emerging problems.

Dashboard Content Standards

Each dashboard should provide sufficient context for interpretation.

Required information should include:

Field Purpose
Dashboard name Clearly identifies the service or purpose
Service ownership Identifies who is responsible for the dashboard
Environment Shows the environment represented
Metric descriptions Explains what each visualisation represents
Units Makes measurements clear
Time range Shows the period being analysed

Visualisations should use appropriate formats.

Data Type Suitable Visualisation
Trends over time Line graphs
Current values Single value panels
Percentages Gauges or single values
Comparisons Bar charts
Distributions Histograms

Avoid visualisations that make interpretation difficult or require unnecessary calculation.

Dashboard and Alerting Relationship

Dashboards and alerts serve different purposes.

Alerts identify conditions that require attention. Dashboards provide context to understand those conditions.

A good operational flow is:

  1. An alert identifies that a service may be impacted.
  2. The engineer opens the relevant dashboard.
  3. The dashboard provides context about what is happening.
  4. Additional metrics help identify the likely cause.

Dashboards should not be used as a substitute for alerting.

Poor approach:

  • Engineers manually watch dashboards waiting for issues.

Better approach:

  • Alerts notify engineers of service-impacting conditions.
  • Dashboards support investigation and diagnosis.

Dashboards and Alert Investigation

Dashboards should provide the information needed to investigate common operational scenarios.

High Error Rate

Dashboard should help answer:

  • Which service is affected?
  • When did the increase begin?
  • Which endpoints are failing?
  • Are failures isolated or widespread?
  • Are dependencies affected?

Increased Latency

Dashboard should help answer:

  • Is latency increasing for all requests?
  • Are specific operations affected?
  • Is the issue related to resource pressure?
  • Are downstream dependencies slower?

Capacity Concerns

Dashboard should help answer:

  • Is usage increasing over time?
  • Are resources approaching limits?
  • Is scaling working as expected?
  • When will additional capacity be required?

Dashboard Naming and Organisation

Dashboards should use consistent naming conventions.

Names should identify:

  • Service or application.
  • Environment.
  • Purpose.

Examples:

Good:

Customer API - Production - Overview
Payment Service - Production - Operations
Database Platform - Capacity Overview

Poor:

Dashboard 1
System View
Production Metrics

Dashboards should be organised so engineers can quickly find relevant information during an incident.

Dashboard Ownership and Maintenance

Every dashboard should have a clear owner responsible for:

  • Ensuring metrics remain accurate.
  • Removing obsolete panels.
  • Updating dashboards when services change.
  • Reviewing dashboard usefulness.

Dashboards should be reviewed periodically to identify:

  • Unused dashboards.
  • Missing operational information.
  • Incorrect metrics.
  • Visualisations that no longer support operational needs.

Unused dashboards increase confusion and make it harder to find reliable information.

Common Dashboard Issues

Issue Impact
Too many metrics displayed Important information becomes difficult to identify
No clear purpose Engineers cannot understand what the dashboard is for
Infrastructure-only dashboards Miss user-impacting issues
No ownership Dashboards become outdated
Missing service context Slower incident investigation
Dashboards used instead of alerts Issues may not be detected quickly
Excessive visual complexity Increases cognitive load during incidents

Dashboard Standards Checklist

Requirement Expected Standard
Purpose Dashboard supports a defined operational question
Focus Service health and user impact
Layout Information ordered for investigation
Metrics Uses meaningful service and platform metrics
Ownership Clear responsible team or service owner
Naming Consistent and descriptive
Context Includes units, descriptions and environment
Alert support Helps investigate alerts
Maintenance Reviewed regularly
Accessibility Clear and understandable during incidents

Effective dashboards provide engineers with the information required to understand service health quickly. They reduce investigation time, support better operational decisions and help teams maintain reliable services.