By the end of Day 12, you will learn:

• How to design actionable dashboards (not just pretty charts)

• Golden Signal dashboards

• SLO dashboards

• Infra / Application / Business KPIs

• Dashboard anti-patterns

• Dashboard governance & best practices

• Tools like Grafana, Kibana, DataDog, New Relic, Azure Workbooks, GCP, CloudWatch

This day transforms monitoring from “data collection” into real decision-making.

A good dashboard must answer 3 questions:

If your dashboard cannot answer these three questions → it's NOT a monitoring dashboard.

Observability teams maintain five categories of dashboards.

Shows health of your service.

Includes:

• Requests per second

• Error rate

• Latency (p50, p95, p99)

• CPU/Memory

• DB latency

• Thread pool usage

• Queue depth

This is the dashboard engineers check during incidents.

Covers:

• VM health

• Container health

• Node CPU/Memory/Disk

• Pod restarts

• Network saturation

• Load balancer availability

• Autoscaler activity

Critical for identifying resource saturation issues.

Used by SRE teams.

Shows:

• SLI (availability, latency, correctness)

• SLO target (% success)

• Error budget (remaining vs burned)

• Burn rate (short-window & long-window)

SLO dashboards decide:

• When to stop deployments

• When to trigger incidents

• When to declare “error budget burn” events

Observed by product teams.

Shows:

• Daily active users

• Orders per minute

• Revenue per hour

• Conversion rate

• Cart abandonment

• API usage by region

Observability = technical + business visibility.

High-level summary:

• Availability

• MTTR

• Incident count

• Deployment success rate

• Cost of logging/metrics

• System uptime

• SLA reports

This is used in weekly and monthly leadership reviews.

Every system MUST have at least these four signals:

These are the foundation of SRE dashboarding.

Use for:

• Latency

• Errors

• CPU

• Memory

• RPS

Use for:

• DB query latency distribution

• Cache hit/miss patterns

• API duration variability

Use for:

• SLO %

• Error budget left

• Active users

• Current CPU %

• Current queue depth

Use for:

• Per-pod or per-node breakdown

• Per-region traffic

• Top N endpoints

• Slowest DB queries

Use for:

• Latency

• Request size

• Memory usage distribution

Use for:

• Tracing

• Profiling

• CPU usage analysis

Here is a common layout for an API service dashboard:

[ Availability / Error Budget / Alerts ]
[ Latency: p50 | p90 | p99 ]
[ Traffic: RPS ]
[ Errors: 4xx, 5xx, timeouts ]
-------------------------------------
[ Upstream dependency latency ]
[ Downstream dependency latency ]
-------------------------------------
[ CPU | Memory | Disk | Network ]
[ Queue Depth | Thread Pool | GC Stats ]
-------------------------------------
[ DB metrics / Cache metrics ]
-------------------------------------
[ Pod-level breakdown table ]

This layout solves 80%+ incident use cases.

❌ Too many panels (dashboard becomes unreadable)
❌ No time window alignment
❌ Missing units (ms, %, MB)
❌ Missing golden signals
❌ Mixing infra + app signals randomly
❌ Using pie charts for monitoring (never do this)
❌ No thresholds or alert markers
❌ Text-heavy dashboards
❌ Panels with no drill-down

Dashboards should be simple, actionable, fast.

• Best dashboard tool globally

• Supports Prometheus, Loki, Elastic, Tempo

• Rich visualization

• Alerting built-in

• Best for log visualizations

• Advanced filtering

• Great for top-N analysis

• Best SaaS dashboarding

• Auto-widgets

• Drag-and-drop panels

• Best native Azure monitoring visualization

• Dynamic queries (KQL)

• Great for dashboards + RCA

• Lightweight

• Metric-based

• Good for infra insights

• Built-in dashboards

• Strong integration with GKE

✔ Keep dashboards simple
✔ Use consistent colors (green=OK, red=Fail)
✔ Left → High-level
✔ Right → Detailed
✔ Top → Golden Signals
✔ Bottom → Infra / Dependencies
✔ Add drill-down links
✔ Use thresholds
✔ Show last deployment timestamp
✔ Limit charts to 10–15 per dashboard

Panels:

• p95 latency

• Error rate

• RPS

• CPU saturation

Query:

sum(rate(container_cpu_usage_seconds_total[5m])) by (pod)

• Redis latency

• DB latency

• External API latency

• Cache hit rate

• SLI success rate

• Burn rate (5m, 30m, 6h, 24h)

• Error budget remaining

• Violations

Latency spike during peak hour.

Old dashboard:

• CPU, memory, disk

• No p99

• No dependency latency

• No DB metrics

• No deployment markers

Result:

• Took 90 minutes for RCA

New dashboard (after redesign):

• p99 latency

• API dependency stats

• Error budget burn graph

• Recent deployment marker

• Pod-level table

RCA took 10 minutes.

Dashboards matter.

• What are golden signals?

• Why do we need dashboards?

• What is the difference between a service dashboard and infra dashboard?

• How do you design an SLO dashboard?

• What widgets do you use for latency vs CPU vs errors?

• How do you avoid dashboard clutter?

• How do you design dashboards for 100+ microservices?

• Why should dashboards include deployment markers?

• Explain drill-down dashboard design.

• Define dashboard governance for a global enterprise.

• How do you standardize dashboards across engineering teams?

• How do you evaluate which metrics belong in dashboards vs alerts?

Dashboards I want to improve:
Golden signals I need to add:
Anti-patterns I need to fix:
New dashboard layout ideas:
Tools I want to experiment with: