Grafana 12 minor upgrades from 12.1 to 12.4

Starting in Grafana 12.4, the Alertmanager cluster metrics carry the grafana_ prefix, so any dashboard panel or alert rule on cluster health that still queries the earlier metric names will stop returning data or start firing on the wrong condition. The change is easy to miss because the panels do not error. They show empty series, and an alert rule that compares against a missing series may resolve, stay silent or misfire depending on how it handles no data. Treat the upgrade to 12.4 as a change to your alerting estate, not only to the Grafana binary.

Start by inventorying every place the old names appear. Search dashboard JSON, Grafana-managed alert rules, provisioning files and any external Prometheus rule files for the Alertmanager cluster metric names your instances export, and compare the list against the names your Grafana 12.4 instances actually expose. Also check whether the same panels are used on NOC wallboards or in reports, since those copies are often outside the folder structure you searched. Record each affected rule with its owner so the fix can be reviewed, not just edited.

Cluster health matters here because high availability alerting relies on these metrics to show whether Alertmanager peers see each other. Without a working view of peer state, a team can miss a split cluster and get duplicate or missing notifications. Before you change any query, read the Grafana alerting high availability documentation to confirm the exact metric names, the labels they carry and the recommended peer and notification checks for your topology. Then update queries in a non-production instance, verify that the series return data and that a deliberately triggered test alert still routes once, and only then promote the change.

Test the 12.4 upgrade against the failures that matter most to an operations team: dashboards that go blank, alert rules that stop evaluating, and notifications that arrive twice or not at all. Run the tests on a copy of production that includes your real data sources, your high availability layout and your provisioned resources, not a fresh install with a few demo dashboards. The most important case is the Alertmanager cluster health metrics, which carry the grafana_ prefix from 12.4 onward. Search every dashboard, alert rule and recording rule for the older metric names, then confirm that the replacement panels show data after the upgrade. An alert that references an old name can keep evaluating without error while it reads no series, so check the rule state, not only whether the rule saved.

Next, test notification routing in your high availability setup. Trigger a test alert and confirm that each contact point receives exactly one notification, since duplicate delivery is the failure the high availability documentation warns about when alerting is not configured for it. Then confirm that provisioned data sources, dashboards, plugins and alerting resources load at startup from the files you deploy, and that a restart on each node produces the same state. Check that the upgraded instance reads the same provisioning directory on every node, because drift between nodes can show up only after a failover.

Plan the rollback before you start the upgrade. Restoring the previous Grafana binary or image is not enough on its own: you need the database backup and the configuration, including provisioning files and plugin versions, restored together so the running version matches the schema it expects. Take the backup while Grafana is stopped or from a consistent database snapshot, and record which Grafana version and plugin versions were running. The grafana upgrade rollback topic covers the downgrade traps in depth, so read it before you rehearse a rollback. Confirm in your own environment whether your Grafana version supports the downgrade path you intend to use between these minors, and whether your database engine and plugins behave the same after a restore.

Target the newest 12.x minor that your upgrade window can absorb, and check its support status before you commit a date. Grafana's upgrade guidance says minor releases arrive about every other month, and each minor is supported for 9 months. The last minor release of a major version gets 15 months instead. That means a minor you stay on past its window stops receiving fixes, so a team that moves from 12.1 to 12.4 in one step is working against a clock that started when each minor shipped, not when your change board approved the work. Confirm the current end-of-support dates for 12.1 through 12.4 on the grafana/grafana releases page rather than relying on a calendar estimate, because the release list is the record you can point an auditor or manager to.

Grafana 13.x is already released, with 13.0 through 13.2 patch and minor builds visible on the same releases page. That changes the planning question. A move from 12.x to 13.x is a major upgrade with its own preparation work, so the team should decide now whether a major upgrade is planned in the next budget cycle. If it is, staying on the last 12.x minor for a short period may be the simpler path, and the 15-month window for the final minor of a major version becomes relevant. If no major upgrade is planned, the 9-month window for each minor is the constraint to watch. Either way, record the chosen target version, its support end date and the date you will next review the decision, so the choice is visible to security and operations owners.

Plan the minor upgrade as a sequence of checks, not a version number change. Before selecting 12.4 or any later minor, review the alerting metric prefix change in that release, the deprecated plugin install settings if you deploy with the Helm chart, and any dashboards or alerts that read Alertmanager cluster metrics. Ask whether your environment runs in a single-node or high-availability setup, because that affects which alerting checks apply. Confirm these items with your own inventory and the release notes for each target version, and treat the minor you choose as a documented commitment with a named owner and a review date.