Grafana has become the default visualization layer for many network teams because it can pull from almost anything: Prometheus, InfluxDB, Elasticsearch, Splunk, SQL databases and many vendor APIs. That flexibility is also a trap. It is easy to build fifty dashboards nobody opens.
After years of building monitoring for data centers and service provider networks, we have found that five dashboards cover most of what a network operations team actually uses. Here is what goes on each one and why.
1. The NOC overview: "Is anything on fire?"
This is the dashboard on the big screen. It has to answer one question within five seconds of looking at it.
What to include:
- Active alarms by severity, as stat panels with color thresholds: critical, major, minor.
- Device reachability as a percentage and a count of unreachable devices.
- Site status map or grid, one tile per site or data hall, colored by the worst active alarm.
- Top 10 interfaces by utilization and top 10 by errors.
- Recent changes, the last five approved changes and when they happened.
Design tips:
- No more than 12 panels. If it scrolls, it is not an overview.
- Use color only for state. Green, amber and red should mean something; decorative color hides problems.
- Set a refresh interval of 30–60 seconds. Faster rarely helps and adds load on your data sources.
2. Interface health: "What is this link doing?"
The dashboard engineers use during troubleshooting. Make it a template: use dashboard variables for device and interface so a single dashboard works for every link.
What to include:
- In/out throughput (bits per second) with the interface speed drawn as a reference line
- Utilization percentage
- Errors and discards (in and out) as rates, not raw counters
- Operational status over time, shown as a state timeline
- Optical levels (Tx/Rx power) for fiber interfaces where available
A typical PromQL query for throughput from SNMP exporter data looks like this:
rate(ifHCInOctets{instance="$device", ifName="$interface"}[5m]) * 8
Always use the 64-bit ifHC* counters for links faster than about 100 Mbps. The 32-bit counters wrap too quickly and produce false spikes.
3. WAN and internet edge: "Are our customers and sites reachable?"
For enterprises, the edge is where most user-visible problems appear. This dashboard focuses on connectivity out of your network.
What to include:
- Circuit utilization per carrier and per site
- Latency, jitter and packet loss to key destinations (from synthetic probes or IP SLA)
- BGP session state and received prefix counts per peer
- SD-WAN path quality if applicable
- Top talkers from flow data (NetFlow/sFlow) for the busiest links
Design tip: Put latency and loss on the same row as utilization. Most "the internet is slow" tickets are explained by a saturated circuit, and seeing both side by side makes that obvious.
4. Capacity planning: "When do we run out?"
This dashboard is for engineering and management, reviewed monthly rather than watched live.
What to include:
- 95th-percentile utilization per link over 90 days
- Growth trend lines, for example using
predict_linearin Prometheus or a trend transform - Links above 70% at the 95th percentile, as a sorted table
- Port capacity per device: used vs. available ports
- Resource trends such as CPU, memory and TCAM/FIB usage on core devices
Design tip: Use the 95th percentile rather than averages or maximums. Averages hide peaks. Maximums overreact to single spikes. The 95th percentile is also how many carriers bill, so it aligns with contract discussions.
5. Change correlation: "Did we do this?"
Industry studies repeatedly find that a large share of outages follow changes. This dashboard makes that relationship visible.
What to include:
- Annotations on every time-series panel for approved changes, pulled from your change management system through its API or a database
- Configuration change events from syslog or your configuration backup tool
- Alarm count over time with the same annotations
- Device reboots and software version changes
Grafana annotations can come from a data source query, so once the integration is set up, every change automatically appears as a vertical marker across all your graphs.
Cross-cutting best practices
Standardize units and naming. Bits per second for throughput (not bytes), percentages from 0 to 100, and consistent device naming. Engineers should never have to guess what a panel shows.
Use folders and permissions. Organize by audience (NOC, Engineering, Management), and restrict edit rights so dashboards don't drift.
Version control your dashboards. Export dashboard JSON to Git or use Grafana's provisioning. When someone "improves" the NOC dashboard at 3 AM, you want a way back.
Link dashboards together. Clicking a device on the NOC overview should open the interface health dashboard with that device preselected. Data links and dashboard links make this easy.
Watch query cost. A dashboard that runs 200 heavy queries every 30 seconds can overload your time-series database. Use recording rules or pre-aggregated data for expensive panels.
Key takeaways
- Five focused dashboards beat fifty unfocused ones.
- Build for a specific audience and a specific question.
- Template with variables so one dashboard serves every device.
- Show changes on the same timeline as problems.
- Treat dashboards as code: version them, review them, and prune the ones nobody uses.
Grafana is at its best when it brings fault, performance and log data into one place. The dashboards above are the foundation. Build them well and the rest of your observability practice has something solid to stand on.