How to Build a Real-Time Dashboard in Grafana
Real-time dashboards turn invisible system behavior into visible signals. Without monitoring, you learn about outages from angry customers. With a well-built Grafana dashboard, you see latency spike before it affects users, catch memory leaks before they cause OOM crashes, and track business metrics alongside infrastructure health in a single pane of glass.
Grafana is the industry standard for operational dashboards because it connects to virtually any data source — Prometheus, InfluxDB, Elasticsearch, PostgreSQL, CloudWatch — and renders them in a unified interface. This guide walks through building a production-grade dashboard from data source configuration to panel design to alerting rules.
Step-by-step guide
Configure your data sources in Grafana
Navigate to Configuration > Data Sources and add each data source your dashboard will query. For infrastructure metrics, add Prometheus or your cloud provider's monitoring service. For application logs, add Elasticsearch or Loki. For business metrics, add your PostgreSQL or MySQL database. Test each connection before proceeding. A dashboard is only as good as its data sources, and a misconfigured connection will show empty panels with no error explanation.
- Add Prometheus for infrastructure and application metrics
- Add Loki or Elasticsearch for log aggregation queries
- Add your application database for business metric queries
Plan the dashboard layout before building panels
Sketch the dashboard structure on paper or a whiteboard first. Group panels into rows by domain: Infrastructure Health (CPU, memory, disk, network), Application Performance (request rate, latency percentiles, error rate), and Business Metrics (active users, transactions, revenue). Place the most critical signals — the ones that indicate an incident — in the top row where they are visible immediately. A dashboard without intentional layout becomes a wall of charts that nobody can parse under pressure.
Create time series panels for core infrastructure metrics
Add panels for CPU utilization, memory usage, disk I/O, and network throughput. Use Prometheus queries like rate(node_cpu_seconds_total[5m]) for CPU and node_memory_MemAvailable_bytes for memory. Set the panel type to Time Series and configure meaningful Y-axis labels and units (percent, bytes, requests/sec). Add threshold lines at your alert levels (e.g., 80% CPU, 90% memory) so operators can see at a glance whether metrics are in the danger zone.
Add application performance panels with SLI tracking
Create panels for request rate (requests per second by endpoint), latency percentiles (p50, p95, p99), and error rate (4xx and 5xx responses per second). Use Prometheus histogram queries for latency: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])). Add a stat panel showing the current SLI compliance — the percentage of time your p99 latency is below the SLO target. These panels answer is the application healthy right now in a glance.
- Add a request rate panel broken down by endpoint or service
- Add p50, p95, and p99 latency panels with SLO threshold lines
- Add an error rate panel with breakdown by HTTP status code
Configure auto-refresh and time range defaults
Set the dashboard's default time range to the last 1 hour with auto-refresh every 30 seconds. This is the right default for an operational dashboard — short enough to show real-time behavior but long enough to show trends. Add a time range override in the dashboard settings so users can zoom out to 24 hours or 7 days for investigation without changing the default. The refresh interval should be fast enough to catch emerging issues but not so fast that it hammers your data sources.
Set up alert rules for critical thresholds
Go to Alerting > Alert Rules and create alerts for the metrics that indicate real incidents. Set alerts for error rate exceeding 1% of total requests, p99 latency exceeding your SLO target, CPU sustained above 85% for 5 minutes, and disk usage above 90%. Configure notification channels (Slack, PagerDuty, email) so alerts reach the right on-call team. The dashboard is for visibility; alerts are for action.
Common mistakes
Putting too many panels on a single dashboard
A dashboard with 40 panels takes too long to load and is impossible to scan during an incident. Keep each dashboard focused on one domain (infrastructure, application, business) with 8-15 panels maximum. Create separate dashboards for deep-dive investigation and link between them.
Using averages instead of percentiles for latency
Average latency hides tail latency problems. If 1% of your requests take 10 seconds but the average is 200ms, the average says everything is fine while 1 in 100 users has a terrible experience. Always use p95 and p99 percentiles for latency monitoring.
Not setting meaningful Y-axis scales and units
A panel showing bytes without unit formatting displays numbers like 1073741824 instead of 1 GB. Configure units (bytes/SI, percent, requests/sec) and set appropriate Y-axis min/max so panels are readable at a glance without mental math.
Tips
Use Grafana's row collapse feature to group less-critical panels in collapsed rows that expand on click, keeping the dashboard scannable while preserving drill-down depth.
Add annotation queries that overlay deployment events on time series panels so you can correlate metric changes with code releases.
Use template variables for service name and environment so one dashboard works across staging, production, and per-service views.
Create a dashboard playlist that cycles through your infrastructure, application, and business dashboards on a TV in the office for ambient visibility.
How Vantage helps
Vantage connects monitoring context to product planning. When performance incidents inform product decisions — like simplifying a feature that causes latency spikes — Vantage captures that context in the PRD so engineering understands the operational motivation behind product requirements.