Dashboards

Design principles, key metrics, operational vs. business dashboards, and how to build views that are actually useful.

What are dashboards for?

A dashboard is a consolidated view of metrics that lets you understand the state of a system at a glance. But not all dashboards are created equal — a poorly designed dashboard can be just as useless as having none at all.

The goal of a good dashboard is not to show as much data as possible, but to answer specific questions quickly and clearly.

Design principles

1. Define the audience

Before building a dashboard, ask yourself: who is going to use it, and for what?

• On-call engineer: Needs to quickly know whether there is a problem and where it is.
• Tech lead: Needs to understand performance and capacity trends.
• Product manager: Needs business and adoption metrics.
• Executive: Needs high-level indicators of health and growth.

Each audience needs a different dashboard.

2. Visual hierarchy

Organize information from most important to least important, top to bottom and left to right:

• Top row: Overall status indicators (traffic lights, large numbers).
• Middle rows: Trend charts for the main metrics.
• Bottom rows: Detail and secondary metrics.

3. Less is more

A dashboard with 30 panels is not more useful than one with 8 well-chosen panels. Every panel should justify its presence by answering a concrete question.

Rule of thumb: if a panel hasn’t changed anyone’s decision in the last 30 days, it probably doesn’t need to be there.

4. Temporal context

Always include:

• Time range selector: Allow switching between the last 6 hours, 24 hours, and 7 days.
• Time comparison: Show the same metric a week ago to detect anomalies.
• Deploy markers: Vertical lines indicating when a deploy happened.

5. Colors with meaning

Use colors consistently and purposefully:

• Green: Everything normal, within SLO.
• Yellow/Orange: Degradation, approaching the threshold.
• Red: Active problem, outside SLO.

Avoid using lots of decorative colors — they distract from and dilute the important signals.

Types of dashboards

Operational dashboard

Designed for the engineering team during day-to-day operations and incident response.

Typical content:

• RED metrics per service (rate, errors, duration).
• Dependency status (databases, queues, external services).
• Infrastructure resources (CPU, memory, disk).
• Active alerts.
• Recent deploys.

Characteristics:

• Real-time updates (refresh every 10-30 seconds).
• Focus on the last few hours.
• Visible thresholds with traffic-light colors.

Service dashboard

A dashboard dedicated to a specific microservice. Every team should have one for each service they maintain.

Typical content:

• RED metrics for the service.
• Latency per endpoint (p50, p95, p99).
• Error rate by error type.
• Downstream dependency metrics.
• Resource usage (CPU, memory, DB connections).
• Message queue (if applicable): size, lag, throughput.

Business dashboard

Designed for non-technical stakeholders who need to understand the impact on the business.

Typical content:

• Orders created per hour/day.
• Revenue processed.
• Checkout conversion rate.
• Active users.
• Average time to complete a key operation.

Characteristics:

• Less frequent updates (every 5-15 minutes).
• Focus on daily/weekly trends.
• Business language, not technical.

SLO dashboard

Shows how the team is meeting its Service Level Objectives.

Typical content:

• Current SLO vs. target (e.g., 99.92% vs. 99.9%).
• Remaining error budget (in minutes or percentage).
• Error budget trend over the last 30 days.
• Incidents that consumed error budget.

This dashboard is key for making prioritization decisions: if the error budget is running out, the team should prioritize stability over features.

Key metrics by component type

For an API Gateway

• Requests per second (total and per route).
• Latency per route (p50, p95, p99).
• 4xx and 5xx error rates.
• Rate limiting triggered.
• Active connections.

For a database

• Queries per second.
• Query latency (p50, p95, p99).
• Active connections vs. maximum pool.
• Replication lag (if applicable).
• Disk usage and growth.

For a message queue

• Messages published per second.
• Messages consumed per second.
• Consumer lag (pending messages).
• Queue size.
• Processing errors (dead letter queue).

For an HTTP service

• RED metrics (rate, errors, duration).
• Status code distribution.
• Latency per endpoint.
• Errors by type (timeout, 500, 503).
• Saturation (queued requests, active threads).

Anti-patterns

The “wall of text” dashboard

Too many small panels with numbers no one can read. Favor a few large, clear panels instead.

The “vanity metrics” dashboard

Metrics that look good but aren’t actionable: “total requests since the beginning of time.” Show rates and trends, not cumulative totals.

The context-free dashboard

Charts with no thresholds, no time comparison, no indication of what “normal” is. Without context, a chart is just a pretty line.

The stale dashboard

A dashboard that doesn’t reflect the current architecture is worse than no dashboard — it creates false confidence. Keep dashboards up to date as part of the development cycle.

A single dashboard for everything

Trying to cram operational, business, and infrastructure metrics into one dashboard. Each audience needs its own view.

Tools

Grafana

The most popular tool for observability dashboards:

• Supports multiple data sources (Prometheus, Elasticsearch, CloudWatch, etc.).
• Templates and variables for dynamic dashboards.
• Built-in alerting.
• An active community with shared dashboards.

Datadog

A SaaS platform that integrates metrics, logs, traces, and dashboards:

• Out-of-the-box dashboards for popular technologies.
• Automatic correlation across signals.
• Notebooks for incident investigation.

Kibana

Part of the ELK stack, specialized in log visualization:

• Dashboards based on Elasticsearch data.
• Ideal for log analysis and search.
• Lens for building visualizations without code.

Best practices

Dashboards as code

Define dashboards in code (JSON, Terraform, Jsonnet) and version them in Git:

• Reproducibility: you can recreate dashboards in any environment.
• Review: dashboard changes go through code review.
• History: you know who changed what and when.

Onboarding with dashboards

When a new member joins the team, dashboards should be part of onboarding:

• “This is the main dashboard for service X.”
• “These are the indicators we look at first during an incident.”
• “This is the team’s SLO dashboard.”

Continuous iteration

Dashboards are not static. After every incident, ask yourself:

• Did the dashboard help me diagnose the problem?
• Was there a metric missing that would have been useful?
• Were there panels that don’t add value?

Summary

Dashboards are the human interface of observability. A good dashboard answers specific questions for a defined audience, uses visual hierarchy to prioritize information, and stays in sync with the architecture. By combining operational, service, business, and SLO dashboards, the team gains complete visibility into system health from multiple perspectives.