Grafana 12.4: What's New, Release History & Support Lifecycle

What Is New in Grafana 12.4

How does Git Sync change dashboard management in Grafana 12.4?

Git Sync is now available in public preview, giving teams a native way to store Grafana dashboards as JSON files in GitHub and manage them through standard Git workflows. This is a significant shift for teams that have struggled to treat dashboards as first-class code artifacts.

In practice, Git Sync enables true dashboard CI/CD: pull requests for dashboard changes, code review before promotion, and rollback via Git history rather than the Grafana version history UI. It complements -- rather than replaces -- file-based provisioning, but the Git-native experience is considerably smoother for teams already operating GitHub-centric workflows.

Watch out for the current public preview status, which means some edge cases and HA configurations may not yet be fully supported. Review the Git Sync usage limitations documentation before rolling this out in production environments.

A minimal configuration looks like the following:

# Grafana configuration (grafana.ini or environment variable equivalent)
[feature_toggles]
kubernetesRepositories = true

# Then configure your repository via the Grafana UI or Terraform:
# Administration > Git Sync > Connect Repository
# Provide: GitHub repo URL, branch, and a GitHub App or PAT credential

Most teams will want to start with a non-production Grafana instance to understand the sync semantics -- particularly how edits made through the UI are reflected back to the remote repository.

What are Dynamic Dashboards and multi-property variables in Grafana 12.4?

Dynamic Dashboards have graduated to public preview in 12.4, bringing a revamped user experience and new capabilities that make it practical to create reusable, parameterized dashboards at scale. The headline addition alongside this promotion is multi-property variables.

Multi-property variables solve a very real pain point: previously, if a single logical concept (say, an environment) had multiple identifiers across different data sources -- for example "dev" vs "development" vs a numeric ID -- you were forced to maintain separate synchronized variables. Now, you map all of those identifiers to a single variable and reference any property in queries and panels using a dot notation.

// Example: a variable named "env" with multiple mapped properties
// In a Prometheus query:
rate(http_requests_total{environment="${env.prometheus_label}"}[5m])

// In a Loki query using the alternative label format:
{env="${env.loki_label}"} |= ""

// Both driven by the same dashboard variable selection

This matters if you run multi-source dashboards -- mixing Prometheus, Loki, and a SQL data source, for instance -- where the same environment is represented differently in each system. The result is fewer variables, less clutter, and dashboards that are easier for other team members to author and maintain.

Additionally, regex filtering can now target the display text of a variable rather than the underlying raw value. This is a simple but effective fix for scenarios where human-readable labels do not match the technical identifiers sent in queries.

What breaking changes and storage migrations should you prepare for before upgrading to Grafana 12.4?

Grafana 12.4 includes three changes classified as breaking that require operator attention before or immediately after upgrading.

Unified Storage for Playlists

On startup, Grafana 12.4 automatically migrates all playlist data from the legacy SQL tables to unified storage. The migration is automatic and validated, but it is a one-way operation for self-managed instances. Ensure you have a recent database backup before upgrading, and verify that any automation or API clients referencing the Playlist HTTP API still work as expected post-migration.

Automatic Storage Migration for Small Instances

Small Grafana instances will have their folders and dashboards automatically moved to Unified Storage on upgrade. There are no visible changes from the user's perspective, but this migration prepares the ground for upcoming storage improvements. This affects self-managed and Grafana Cloud instances that fall below the size threshold. No configuration is required, but the migration is irreversible.

Plugin Environment Variable Isolation

Starting in 12.4, plugin processes no longer inherit the full set of environment variables from the Grafana host process. This is a security hardening measure, but it can break plugins or data source backends that rely on environment variables being implicitly passed -- for example, cloud credential chains injected via AWS_PROFILE, GOOGLE_APPLICATION_CREDENTIALS, or similar patterns.

# To explicitly pass environment variables to plugin processes,
# configure them in grafana.ini under the plugin section:
[plugin.your-plugin-id]
env = AWS_PROFILE=myprofile
env = MY_CUSTOM_VAR=value

Most teams running data source plugins that use ambient cloud credentials will need to audit and explicitly allowlist the required variables before upgrading.

How do the logging and alerting improvements in Grafana 12.4 affect day-to-day operations?

Grafana 12.4 brings several targeted quality-of-life improvements to both Logs Drilldown and Alerting that reduce repetitive work during incident investigations.

Logs Drilldown: Save Explorations and Default Columns

You can now save a log exploration in Logs Drilldown -- including all active filters -- and return to it later without reconstructing your query context. This is genuinely useful for recurring investigation workflows, on-call runbooks, or when handing off an open incident to another engineer mid-shift.

Administrators can also configure default columns for Logs Drilldown from the plugin configuration page, scoped per service or label set. Instead of users always starting from a generic column layout, the relevant fields surface immediately on load. This matters if you have high-cardinality log streams where the important context (trace ID, request ID, user ID) is buried in metadata rather than the log body.

OpenTelemetry Log Display

Grafana now applies smarter defaults for OTel-structured log lines. Previously, resource attributes, log fields, and log attributes were only visible by expanding a log line -- important context was easy to miss in high-volume streams. The new defaults surface this structured metadata as visible columns, reflecting how OTel producers actually distribute information.

Alerting: Pending Period for NoData and Error States

NoData and Error alert states now respect the same pending period as standard threshold alerts. Before this change, a single evaluation cycle resulting in NoData or an evaluation error would immediately fire a notification -- a significant source of alert noise in environments with flapping data sources or transient scrape failures. Now, notifications are held until the pending period elapses, giving you the same noise-reduction control you already have for value-threshold alerts.

What usability and security improvements did Grafana 12.4 introduce for enterprise teams?

Two enterprise-focused improvements in 12.4 are worth highlighting for teams managing Grafana at scale: SCIM provisioning reaching GA and RBAC for saved queries.

SCIM User and Team Provisioning (GA)

SCIM support moves from public preview to general availability, and critically, it removes the "first login" requirement. Previously, SCIM could sync user records from an identity provider (Okta, Entra ID, and so on), but certain configuration tasks -- such as assigning team memberships or pre-configuring access -- still depended on the user logging in at least once to initialize their Grafana account. That bottleneck is now eliminated. Centralized operators can fully provision and configure users before they ever open the application, which is important for regulated environments where access must be demonstrated before use.

RBAC for Saved Queries

Saved queries in Explore now have consistent role-based permissions rather than a per-query sharing checkbox. Queries are shared by default with all users who have access, while only users with the Writer role can create, modify, or delete them. This replaces an inconsistent opt-in model with a predictable, auditable permission structure that aligns with how permissions work elsewhere in Grafana.

The shift from per-resource checkboxes to role-based defaults is a pattern Grafana has been pursuing across the product. In practice, it reduces the surface area for misconfigured sharing and makes it easier to reason about who can do what in a large shared instance.