Grafana beyond CPU charts

CPU, memory, disk. Useful charts. But the questions I need to answer during daily operations usually go further. Did the backup actually finish? What changed before the alert? Which cloud resources are driving the bill? Is a certificate about to expire?

The observability platform I designed, built and operate brings those questions into one workspace. In my October 2026 snapshot, it had 40+ dashboards managed as code and processed millions of log lines a day. The interesting part is what that data helps me do. Ideally without opening half the browser to understand one problem. 🙂

What Grafana does, and what sits behind it

Grafana is where I query, explore and visualise the data. It is not the database holding all my telemetry. Data sources connect it to the systems that store that information. Grafana’s introduction explains that distinction well.

In my stack, Prometheus handles metrics and VictoriaLogs handles central logs. Exporters, Grafana Alloy and custom collectors bring the data in. That covers Linux and Windows host metrics, process information, system events and application logs. Some machines can be scraped directly; others need an agent that pushes data out. Collection follows the connectivity available to each workload.

The same approach works for information that does not begin as a CPU metric. A collector can read an API, keep the useful fields and expose them to a data source Grafana understands. That is how operational questions start becoming dashboards.

A few things I use it for

Backups and availability

A machine being online does not tell me whether its backups are healthy. Backup monitoring adds job status, freshness and failures to the picture. Service probes answer another question: can the service actually be reached?

For availability, I use probes that check the service from outside its own process. HTTP responses, response times and TLS certificate dates make a more useful picture than a green VM icon on its own. Historical probe results can also feed an availability report with a stated measurement period.

I keep those signals separate. An uptime result is not a recovery test. They answer different questions, and both deserve a clear place on the screen.

Cloud costs alongside infrastructure

Custom collectors bring Azure and IONOS cost data into dashboards. I can look at spending over time, compare periods and investigate which resources or services account for a change. Azure Advisor recommendations add another source of context.

The collection work happens outside Grafana. The dashboard makes the results easier to explore. Billing data also has its own update cycle; a chart does not turn it into a real-time invoice.

DNS changes and things that expire

A DNS auditor checks records and produces findings that can be reviewed in Grafana. Automation around it can turn new findings into Jira work through n8n. The useful output is a finding with context and a place to follow it up.

Credential expiry is another practical example. Collectors and workflows bring in certificate and token expiry dates. Some dates come from APIs; others need a maintained register. The dashboard shows identifiers and dates, not secret values.

Logs, incidents and changes in the same investigation

When a metric moves, I want to see the logs from the same time window. The VictoriaLogs data source lets me filter and explore logs from Grafana, including through Explore.

Structured deployment records, pipeline results and incident history add context around those signals. A deployment near an error spike is a useful lead. It still needs investigation before I call it the cause.

Consistent labels matter here. Host, service and environment names need to mean the same thing across the data sources. Otherwise I have several attractive dashboards and still have to join everything together in my head.

The mini graph above is a made-up example of that investigation. First I notice response time and error activity changing near a deployment marker. Then I narrow the time window, open the relevant logs and inspect the change record. The graph gives me a starting point. The evidence comes from the investigation.

More modules I have used or tested

There is no single plugin that turns Grafana into all of this. The useful part is connecting the right source to a question, then keeping that connection healthy. These are other modules I have worked with around the same stack:

• Firewall security. OPNsense events become views of blocked traffic, intrusion-detection signals and activity over time. The collection and detection happen in the surrounding systems. Grafana helps me explore the patterns and drill into the events behind them.

• Windows patch and device compliance. Data from Windows Update for Business and Microsoft Entra ID can show reported build versions, update status and how the estate changes over time. Source freshness matters: a device that has not reported recently needs a different interpretation from one confirmed as current.

• Incident history. PagerDuty records add open incidents, acknowledgement and resolution history to operational views. This gives me a way to examine repeated alerts and their context, rather than relying on whoever happens to remember the previous incident.

• Delivery and work tracking. Azure DevOps data supports views of pipeline outcomes, run duration, agent waiting time and work-item flow. A slow delivery can come from a failing step, a queue or blocked work. Separate views help me ask a more precise question before changing anything.

• Automation health. n8n execution records show which workflows ran, which failed and whether scheduled work is still happening. Keeping that history in the logging platform also makes it available alongside other signals. The workflow sending those records needs its own health signal too.

• AI usage. Usage records and scheduled exports can show activity, consumption and utilisation for the AI services included in the integration. I keep that separate from observability of an individual model request. A usage dashboard does not automatically give me prompts, traces or the quality of an answer.

• AI-assisted investigation. I have also tested querying Grafana through an MCP integration from an AI assistant. The useful starting point is read-only investigation: find a dashboard, query a signal, inspect a time range. Query results still need checking, especially when an assistant proposes a conclusion from incomplete context.

The same pattern keeps coming back. Get useful data, preserve its meaning and make the next action clearer. More panels on their own do not make the platform better.

Alerts and reports need a workflow

Grafana Alerting evaluates selected conditions and routes notifications to contact points such as Teams or PagerDuty. In my setup, n8n and custom automation handle additional operational workflows. An alert is more useful when someone knows what it means and what to check next.

Scheduled availability and performance reports use custom jobs and rendered dashboard data. I also use generated data exports where a CSV or spreadsheet is more practical for the recipient. Schedules, delivery and archives are part of the surrounding automation, with their own status to watch.

This is a custom reporting workflow built around the stack. Grafana’s built-in reporting options depend on the edition; the reporting documentation describes those separately.

I also need to observe the collectors and reporting jobs themselves. A quiet dashboard is only reassuring when the data behind it is still arriving.

Keep the platform in code

Dashboards, data sources, alert rules and configuration belong in version control. Terraform handles cloud resources; Ansible handles configuration and deployment through Azure DevOps. Changes can be reviewed, validated and reproduced.

Grafana supports file provisioning for dashboards and data sources and alerting resources. In my platform, the durable version of a change belongs in Git, rather than only in a browser session.

Identity and access belong in that operating model as well. I have used Microsoft Entra ID sign-in, Grafana roles and separate organisations where teams need different working spaces. A useful dashboard still needs an appropriate audience; signing in is only one part of that decision.

I also use Grafana Advisor as another check on the platform itself: data-source health, plugins and authentication configuration. It is a useful review tool alongside collector health, retention planning and recovery procedures. Running the containers is the beginning of operating the stack.

I have described the broader design in the observability project. For a smaller lab, I would start with one service, its metrics, its logs and one alert I know how to act on. Then add the next operational question.