What's new in Grafana Cloud

You now have more flexibility to tailor Grafana IRM to your team’s specific incident response workflows with several new customization options:

• Custom incident statuses: Define additional phases, such as Investigating or Monitoring, to go beyond the default Active and Resolved statuses. Custom statuses help responders communicate progress more clearly and give stakeholders better visibility into the state of an incident.
• Custom metadata fields: Capture the information that matters most to your organization. Add custom fields, such as impacted services or involved teams, and even make them required to ensure consistent data collection across incidents.
• Private incidents: Limit visibility for sensitive incidents by declaring them privately. Private incidents automatically create a restricted Slack or Microsoft Teams channel and give you control over who has access throughout the incident.

To learn more, refer to the documentation on incident settings and private incidents.

Dynamic Alerting with our Forecasting and Outlier Detection features has been supporting role-based access control in Public Preview for the last months. We’re excited to announce that this feature is now generally available. This introduces the roles ML Editor, ML Viewer, Sift Editor and Sift Viewer to better manage access to our Dynamic Alerting features.

ML Editors can:

• Create/edit/delete forecasts and outlier detectors
• Create/edit/delete holidays

We’re excited to roll out three powerful enhancements to TraceQL, giving you more flexibility and performance when querying traces in Grafana Cloud with Tempo.

• Rank your metrics with new topk(n) and bottomk(n) functions to quickly get your highest and lowest ranking time series.
• Aggregate spans over time using sum_over_time() for built-in cumulative sums, such as total bytes, error counts.
• Fetch the latest traces first via the experimental most_recent=true query hint.

Ranking topk and bottomk functions for TraceQL metrics

When you’re looking at latency, error rates, or throughput across hundreds or thousands of services or endpoints, it’s easy to get lost in all the data. Previously, you’d have to pull back the full set of aggregates and then manually inspect or post‑process the results to find your worst offenders or best performers.

Segmentation allows customers to manage their Adaptive Metrics recommendations on a team, service, or system level, allowing for more granular management of Adaptive Metrics.

You can define label-based segments via a GUI, API, or Terraform. Each segment will then receive its own recommendations; rules and exemptions can then be managed per segment.

Logs Drilldown now contains a JSON viewer for structured log lines. With this new feature, users can more easily view, interact, and of course drill down into their JSON data. This table enables users to filter their JSON log lines so that they can view just the data they need in places like the Log Volume visualization.

To learn more, refer to the following video demo, as well as the Grafana Logs Drilldown documentation.

We’ve simplified the migration of data source-managed alert rules to Grafana-managed alert rules.

Using these tools and APIs, you can import data source-managed alert rules from Prometheus-compatible systems (Prometheus, Mimir, Loki) into Grafana as Grafana-managed alert rules. This simplifies migrating from data source alerts to Grafana Managed Alerts while preserving behavior of the rules. Alert rules can be imported from an easy-to-use UI tool or through API endpoints compatible with Mimirtool.

Flapping alerts can cause noise and obscure other issues. Now you can set the minimum amount of time that an alert remains firing after the breached threshold expression no longer returns any results. This sets an alert to a “Recovering” state for a duration of time so a re-triggered threshold incurred during this period won’t trigger a new alert.

Read the documentation for more information about how to set a “ Keep firing for” duration so you can use the Recovering state to eliminate unwanted noise.

You can now restore or permanently delete recently deleted Grafana-managed alert rules. Go to Alerts & IRM > Alerting > Recently deleted to see this function in action.

The table visualization panel just got a major performance boost. Load, sort, and filter large tables many times faster than before, now that the table visualization has been refactored to use the react-data-grid library.

Enhancements:

Performance: On a simulated large table of 41,400 rows and 17 columns, we see the following improvements:

If the feature flag for dynamic dashboards is enabled, once an existing dashboard is migrated to a dynamic dashboard and using schema v2, it can’t be migrated back. This issue will be solved in future versions of Grafana.

The issue only exists for self-managed users that want to roll back to a previous version of Grafana and users that provision dashboards as code. Grafana v12 has a mechanism to resolve both versions. 

We were double registering the existing metric cache_size. In Grafana v12 we’re deprecating the metric, with plans to remove it in Grafana v13, and splitting it into 2 different metrics:

• resource_cache_size
• query_cache_size

While available metrics are not officially documented, you may still use them to get information on the state of your instance.

Migration/mitigation

We’re removing the deprecated version of the UI extension APIs in favor of the new reactive APIs introduced in Grafana v11.4. The new APIs enable Grafana to load plugins with UI extensions lazily when needed instead of needing to load them prior to starting Grafana. They also make the UI reactive, so when the UI extensions registry changes, it will be reflected in the UI.

This affects plugin developers that are using UI extensions and haven’t migrated to the new APIs yet. Plugins trying to use the deprecated APIs in Grafana v12 throw an error.

Migration/mitigation

We’ve had a standard way to define UIDs for Grafana objects for several years. While all of our internal code complies to this format, we didn’t yet have strict enforcement of this format in REST APIs and provisioning paths that allow the creation and update of data sources.

In Grafana v11.2, we added a new failWrongDSUID feature toggle that is turned off by default. When enabled, the REST APIs and provisioning reject any requests to create or update data source instances that have an incorrect UID.

Use the full power of SQL to manipulate and combine results from data sources however you like. You can use it to create new dashboard visualizations and powerful alert and recording rules.

You can filter, do math, and join across different data source types at run time.

Aggregate by was introduced as a way to view RED metrics for your traces in the Tempo data source. This functionality has been deprecated since Grafana v11.3 in favor of using Traces Drilldown and the TraceQL metrics API, which offers much more functionality and complex features. Additionally, TraceQL metrics queries are significantly more powerful than what the metrics summary API provides.

Migration/mitigation

RED metrics are supported via Traces Drilldown and can be viewed with more advanced context than via the older metrics summary API. For all users, the aggregate by section will no longer be present in the Tempo data source search tab. Additionally, any user that had been using the aggregate by functionality in the Tempo data source in a dashboard can manually change the Tempo query.