You are asked to build the main Grafana dashboard for a web API. What would you put on it, and how would you lay it out?

What the interviewer wants to hear

• Start with user-facing signals: traffic, errors, latency percentiles
• Show SLO status and remaining error budget near the top
• Add saturation of key resources such as CPU, memory and pools
• Include dependencies and recent deploys as annotations
• Use variables for environment and service, and keep it focused

Model answer

I would design it to answer one question first: are users OK right now? The top row shows SLO status and error budget remaining, then request rate, error rate and latency as p50, p95 and p99, not averages. The next row shows saturation: CPU, memory, connection pool usage and queue depth, because these explain why latency rises. Then a row for key dependencies, such as database and downstream service latency and errors. I add deploy annotations so it is easy to see whether a change lines up with a spike. Variables let people pick the environment, region and service, so one dashboard works everywhere. I keep it short and link to more detailed dashboards and to the runbook, because an on-call engineer at 3 a.m. needs a clear picture, not fifty panels.

More easy Site Reliability Engineer questions

• Explain the difference between an SLI, an SLO and an SLA, with an example.
• What is an error budget and how does a team use it?
• What are the four golden signals, and why are they useful for monitoring?
• You are on call and get paged for a high error rate. What are your first steps?
• What is toil, and how would you reduce it on your team?
• What is the difference between monitoring and observability, and what are metrics, logs and traces each good for?
• Why do SRE teams manage infrastructure with code tools such as Terraform instead of clicking in a cloud console?
• Explain blue-green and canary deployments. When would you choose each?
• What makes an on-call rotation healthy and sustainable for the engineers on it?