Grafana observability dashboards can now be customized without leaving the application. This changes control over observability at the service and instance levels.
As long as teams operate on default dashboards, everything looks acceptable. However, as the number of services and operational scenarios grows, standard views begin to diverge from actual workflows. A gap arises between how the system displays data and how engineers make decisions. This is especially noticeable in Cloud Provider Observability: there is a quick start with ready-made panels for AWS, Azure, and GCP, but the depth of customization is limited, and drill-down at the instance level often does not reflect the necessary metrics and queries.
The solution in Grafana 13 is to provide control over the entry point and granularity without breaking existing templates. There is now the ability to connect existing dashboards, generate new ones through AI, and redefine instance drill-down. This is a compromise solution: the value of out-of-the-box views is preserved, but an additional layer of customization is added. The key idea is a unified configuration at the service level, which is then used across all surfaces: service pages, Database Observability, entity graph, and transitions from alerts. This approach reduces fragmentation and eliminates logic duplication.
Implementation is tied to the configure page of a specific service. On the Services tab, you can select the desired service and define which dashboard will be the primary one. If there is already a proven internal dashboard, it can be connected as a quick link and set as default. Meanwhile, the standard dashboard does not disappear — it remains available as an alternative. If there is no dashboard, AI generation is used: the system creates a template with variables and panels in the RED/USE style. This accelerates the start but leaves the responsibility for final validation with the team.
An additional layer is the configuration of drill-down for instances. Here, you can change the composition of panels, queries, display order, units of measurement, and legend formats. An important point: this configuration is applied consistently across all entry points. Regardless of whether the user came from Cloud Provider Observability, Database Observability, or from an alert, they will see the same representation. This reduces cognitive load and simplifies onboarding.
The results are architectural rather than quantitative — improvement metrics are not specified. But the causal relationship is clear: a unified configuration reduces divergence between teams, custom dashboards increase the relevance of signals, and AI generation decreases the time to the first useful representation. However, trade-offs remain. The more customization, the higher the risk of standard divergence within the organization. Additionally, AI generation speeds up creation but does not guarantee the correctness of queries and metric interpretation.
In an industrial context, this appears as an evolutionary improvement. Observability has long been shifting from static dashboards to adaptive representations, closer to team tasks. Grafana is taking a step towards “config-as-a-view,” where the service defines how it should be observed. This reduces friction between the platform team and product teams but requires discipline in configuration management.
From a practical standpoint, the approach is justified where there is a variety of services and different operational models. If the infrastructure is homogeneous, standard dashboards may remain sufficient. The new model does not eliminate basic views but adds a layer of management. And it is this layer that becomes the point where the maturity of SRE practices manifests.