What upgrades and support involve for Grafana
Keeping a self-hosted Grafana instance on a supported release is a recurring operating task, and the release schedule sets its pace. Grafana's upgrade guidance describes one major release a year, usually in April or May, minor releases about every other month and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version is supported for 15 months. When a minor release leaves its window, it stops receiving fixes, so the operator must move to a newer minor release before that date. Confirm your current version and its end-of-support date before you set the upgrade calendar.
Patch releases deserve the most routine attention because they carry security and defect fixes without the behavior changes that come with minor and major releases. The grafana/grafana releases page lists patch releases 13.2.4, 13.1.8 and 13.0.11, all published on October 13, 2026, which shows several supported lines receiving fixes at the same time. An instance that stays on an old patch level keeps defects and vulnerabilities that a later patch already fixes. Watch the releases page and any published security notices for your version, and set a patching window that your change process can actually meet.
Four situations usually trigger the work. A new major version requires a review of breaking changes, plugin compatibility, and database and configuration settings before the upgrade is scheduled. An end-of-support warning means the installed minor release is nearing the end of its window. A security advisory calls for an out-of-cycle patch that may need to move ahead of planned changes. A broken plugin after an update usually means the plugin must be updated, pinned to a working version or removed, and each option needs testing on a copy of the instance first. Keep a current inventory of installed plugins and their versions so that this check can be run quickly during an incident.
A team with Grafana operations experience can usually run routine minor and patch updates in house, provided it tests on a staging copy, backs up the database and keeps a tested rollback path. Outside help is most often requested for major versions, for multi-instance or high availability setups that share a MySQL or PostgreSQL database and need alerting checked for duplicate notifications, and for compliance-driven change control that requires evidence for each change. Ongoing support, upgrades and testing can be bought as a retainer, and the written scope should name the release lines, environments and response expectations covered. First deployment, migration and dashboard design are covered on their own pages.
What the upgrade and support work includes
Grafana upgrades touch the server, its database, plugins and every data source connection, so the work is packaged in stages with written outputs at each step. The exact coverage of any retainer is set in the written scope.
Release tracking and upgrade planning
Grafana ships major releases once a year, minor releases every other month and patch releases at least monthly, and each minor release is supported for 9 months while the last minor of a major is supported for 15 months. We map your running version against those windows, flag breaking changes between majors and agree a target version and date range with your team. Confirm which release channel and window your security policy requires.
Pre-upgrade inventory
Before any change, we record the running Grafana version, the database backend (SQLite, MySQL or PostgreSQL), installed plugins, configured data sources, provisioned dashboards and alert rules, and the authentication method in use. This inventory shows which items will break or need review. Ask for it to be kept as a versioned document so the next upgrade starts from current facts.
Staging rehearsal
We run the planned upgrade on a copy of production configuration and data, using the same database engine and authentication setup. The rehearsal exposes configuration changes, plugin failures and migration steps that only appear with real content. Confirm that staging matches production closely enough that the rehearsal result can be trusted before the production window is booked.
Production upgrade and rollback plan
The production change follows the runbook from the rehearsal, with a defined backup point, a go or no-go check and a rollback procedure tested in staging. Because database migrations can make an older binary unable to read the schema, the rollback depends on a restorable database backup taken before the change. Confirm who approves the change and how long a rollback is allowed to take.
Post-upgrade verification
After the change, we check dashboards render, alert rules evaluate and route to their contact points, and each data source connection returns results. The checks follow a written checklist so the team signs off on the same items every time. Include your highest-impact dashboards and on-call alert paths in the checklist.
Plugin compatibility review
Plugins are versioned separately from Grafana core, so an upgrade can leave a plugin unsupported or behaving differently. We check each installed plugin against the target Grafana version, note any replacement or removal needed, and test the panels that depend on it. Ask for every plugin's source and license to be listed in the inventory.
Security patch application
Patch releases address security issues in Grafana, and they are applied on a planned cadence rather than only at major upgrades. Each patch goes through the same staging and verification steps as a minor upgrade, scaled to its size. Confirm how urgent advisories are handled and who decides when an out-of-cycle patch is applied.
Ongoing support scope
Support covers incident response hours, patch cadence, advisory monitoring and a change calendar that schedules upgrades around your freeze periods. The hours, response expectations and included systems are defined in the written support scope, not assumed. When comparing retainers, check whether data source troubleshooting and plugin fixes are inside or outside that scope.
What drives upgrade and support effort
This table lists the factors that change how much work each Grafana upgrade and ongoing support engagement involves, why each one matters, and how to keep it manageable.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of instances and HA | Each instance is upgraded and checked, and HA pairs need rolling upgrades behind the load balancer with alerting checked for duplicate notifications. | Standardize builds with packages, Docker images or Helm charts, and upgrade one node at a time with a documented rollback. |
| Database backend | SQLite is the default and not for production. Moving to MySQL 8.0 or later or PostgreSQL 12 or later adds database migration and backup steps to every upgrade. | Migrate to a supported production database before the first upgrade in scope, and confirm your backup and restore process for it. |
| Installed plugins | Plugins have their own versions and compatibility with the Grafana release. Unsigned or community plugins may need manual review and can break on upgrade. | Keep a plugin inventory, remove unused plugins, and prefer signed plugins with a named owner for each one. |
| Provisioned versus UI-managed dashboards and alerts | UI-managed objects must be exported, compared and retested by hand after each upgrade. Provisioned files are reviewed in version control. | Move dashboards, data sources and alert rules to provisioning or Git-based workflows so changes are tracked and repeatable. |
| Data sources and version coupling | Upgrading Grafana can change how it talks to Prometheus, Loki, SQL or other data sources, and each source has its own upgrade cycle. | List every data source with its version, test queries against a staging copy and confirm supported combinations before upgrading. |
| Authentication setup | Enterprise-only SAML, team sync and SCIM need a licensed edition. Open source LDAP or OAuth setups need their own testing after each upgrade. | Document the identity method in use, confirm which features your edition provides, and include sign-in tests in every upgrade check. |
| Custom code or embedded Grafana | Custom app plugins, forks or embedded dashboards depend on internal APIs and frontend code that can change between releases. | Keep custom code in a repository with tests, pin dependencies, and review release notes for each targeted version. |
| Number of environments and change control | Each environment (dev, staging, production) is upgraded in order, and change-control rules add approvals, evidence and scheduled windows. | Use a fixed promotion path, automate deployments where your policy allows, and keep change records for each step. |
| Gap between installed and current version | A longer gap usually means more breaking changes to review at once. Minor releases are supported for 9 months and the last minor of a major for 15 months, so an older install may already be out of support. | Upgrade on a regular cadence, with patch releases applied at least monthly, and check the release notes for every version between your current and target release. |
How an upgrade engagement runs
The sequence moves a Grafana installation to a supported target version through checked stages, with rollback ready and ownership handed back to your team.
Inventory the current installation
We record the installed version, backend database, installed plugins, data sources, authentication method, and provisioning state, including which dashboards and alerts are file-provisioned and which were edited in the UI. The output is a written inventory that both teams sign off before any change is planned.
Choose the target version against support windows
We review the release notes and breaking changes between the current and candidate versions, then select a target that keeps the installation inside a supported minor release under Grafana's support windows. The output is a short review listing each breaking change, its affected components, and the agreed target version.
Rehearse the upgrade in staging
We build a staging copy from a recent backup of your configuration and database, then run the upgrade end to end. The rehearsal records the steps, errors, and timings, and the output is a tested runbook for production with each step verified.
Test plugins and data sources for compatibility
We check each installed plugin and data source connection against the target version, replacing or pinning anything that does not load or query correctly. The output is a compatibility matrix that names each component, its status, and the action taken.
Run the production change window with rollback ready
We perform the upgrade in the agreed change window, following the rehearsed runbook, with a verified backup and a documented rollback path held ready throughout. The change is complete when the service starts on the target version and the checks in the runbook pass.
Validate dashboards and alerts with owners
Your dashboard and alert owners review their dashboards, queries, and alert rules on the upgraded instance while we check notification delivery. The output is a signed validation list confirming each critical dashboard and alert works as expected or a recorded fix.
Hand over the runbook and support schedule
We deliver the updated runbook, configuration records, and the support schedule for patch and minor releases, then walk your operators through them. The engagement closes when your team confirms receipt and the support terms are agreed in writing.
What stays in-house and what teams outsource
This table shows which Grafana upgrade and support tasks usually remain with the internal team and which are commonly handed to a partner, with the skills each task requires.
| Work area | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Change windows and business acceptance | Approving upgrade dates, freeze periods and sign-off from dashboard owners and on-call leads | Preparing the change request, impact summary and rollback criteria for each window | Change management, knowledge of business-critical dashboards |
| Dashboards and alert rules | Owning content, folders, permissions and which alerts page people | Auditing dashboards and alert rules for breakage after an upgrade and fixing query changes | Grafana provisioning knowledge, PromQL or LogQL, alerting design |
| Data source and plugin owners | Naming accountable owners for each data source and each installed plugin | Checking plugin compatibility against the target version and flagging unmaintained plugins | Data source administration, plugin lifecycle, vendor documentation review |
| Staging rehearsal | Deciding which dashboards and alerts must pass in staging before production | Running the rehearsal on a production-like copy, with database backup and restore tests | Linux administration, MySQL or PostgreSQL administration, Grafana provisioning |
| Production upgrade and rollback | Holding the authority to approve go or no-go at the window | Executing the in-place or rolling upgrade and a documented rollback path, using a repeatable runbook | Linux and reverse proxy administration, database administration, change management |
| Breaking-change notes against your configuration | Confirming which settings, data sources and integrations your team actually uses | Mapping each breaking change in the release notes to your provisioning files, auth settings and data sources | Grafana provisioning knowledge, identity administration, reading release notes |
| Security advisories and patches | Deciding risk acceptance and approving emergency patch windows | Tracking advisories, testing patch releases and applying them on the agreed cadence | Linux administration, reverse proxy hardening, identity administration |
| On-call response for Grafana itself | Owning escalation paths for user-facing outages and access requests | Providing monitoring for the Grafana service, runbooks for restarts and database failover, and after-hours coverage where contracted | Linux administration, database administration, reverse proxy administration |
What usually goes wrong with Grafana upgrades
Most Grafana upgrade problems come from skipped rehearsals, drifting configuration and unplanned version gaps rather than from the upgrade itself. Each card names the symptom to watch for and the control that prevents it.
Production upgrades without rehearsal or backup
Teams often upgrade the production instance directly, then find dashboards, data source queries or database migrations behaving differently. Rehearse the upgrade on a staging copy built from a recent production database backup, and confirm that backup restores before any schema migration runs. Record the rollback path before the change window opens.
Installations outside support windows
Each minor release is supported for 9 months, and the last minor release of a major version for 15 months. An installation that falls outside these windows stops receiving fixes, including security patches. Check the installed version against the release calendar each quarter, and schedule minor upgrades before the window closes instead of waiting for an incident.
Plugin breakage after major releases
Plugins built for the previous major can fail to load, lose panel options or stop rendering after a major upgrade. Inventory every installed plugin, its source and its version before the upgrade, and check each one against the target release notes. Test the critical dashboards in staging, and keep an unvetted or unmaintained plugin out of production until it passes that test.
Provisioned files and UI drift
Provisioned data sources and dashboards can fail to load after a version change, or load with altered defaults that change behavior without any visible error. Separately, edits made in the UI to provisioned objects can be overwritten or diverge from the repository. Validate every provisioning file in staging, make the repository the only source of change, and review the startup logs after each restart.
Alert rules and contact points changing
Alert evaluation, notification routing or template rendering can behave differently after an upgrade, so pages stop firing or send duplicates. Export alert rules, contact points and notification policies before the change, then replay representative test alerts in staging and confirm each route reaches its receiver. Keep silences and mute timings documented so they survive the upgrade.
HA nodes running mixed versions
In a high availability setup, nodes sharing one database can run different versions for longer than planned if the rolling upgrade stalls. Mixed versions can produce inconsistent behavior for users and for alerting. Set a maximum window for the rollout, upgrade every node in one planned sequence, and confirm that all nodes report the same version before closing the change.
How upgrade work changes by starting point
A packaged install on Debian, Ubuntu, RHEL, Fedora or SUSE is the simplest upgrade path because the package manager delivers each release. The work centers on the host, its configuration file and the database Grafana already uses.
- Package source: confirm whether the host pulls from the official Grafana repository or an internal mirror, and which release channel it follows.
- Configuration and plugins: compare the configuration file and installed plugins with the target release before the package update.
- Database backup: back up the SQLite file or the MySQL or PostgreSQL database before any package change.
- Rollback: agree a maintenance window and keep the previous package version available for rollback.
Confirm with the team who owns OS patching, and whether automatic updates could move Grafana across a major version without a planned review.
On Kubernetes, the plan starts with the Helm chart version and the Grafana image tag, which together define the running build. Values files, sidecars and storage often matter as much as the image.
- Chart and image pinning: confirm that the chart version maps to the Grafana image you intend to run, and read the release notes for both.
- Values diff: render manifests for the current and target chart versions and compare them to catch changed defaults.
- Persistent storage: confirm that database and plugin volumes survive pod replacement and are covered by backups.
- Rollout behavior: review the deployment strategy and readiness probes so a failed upgrade does not remove every replica.
Confirm with the cluster team whether these releases go through GitOps, and which image registry the organization approves.
A high availability setup runs two or more active-active Grafana servers that share one MySQL or PostgreSQL database. Each upgrade has to keep users served while nodes move to the new build, and nodes may briefly run different versions.
- Rolling order: define the node sequence and the time nodes may run mixed versions, and test that window before production.
- Schema migration: confirm which node runs database migrations and whether a restore point has been tested.
- Alerting safeguards: keep the alert deduplication settings in place, since the docs note that HA alerting needs additional configuration.
- Load balancer draining: check health checks and session handling so users move off the node being upgraded.
Confirm with the database team whether schema changes need their approval, and who runs the failover test.
An installation that has stayed on an old major for a long time needs several stepped upgrades, because majors arrive once a year and each can carry breaking changes. Each step must be tested before the next one starts.
- Support status: check whether the installed minor is still inside its support window, since each minor is supported for 9 months and the last minor of a major for 15 months.
- Breaking changes: read the breaking-change notes for every major between the installed version and the target, not only the final one.
- Stepped path: rehearse each intermediate upgrade on a copy of production data and record what each step changes.
- Plugin compatibility: confirm that each plugin has a version compatible with every step, and remove unused plugins early.
Confirm with the team whether any data sources also need upgrading before the target Grafana version can connect to them.
In an air-gapped or restricted network, packages, Docker images, Helm charts and plugins must be mirrored in, verified and approved before they reach the environment. The release schedule then follows the transfer schedule.
- Mirror scope: list every package, image, chart and plugin for the target and each intermediate version, along with their dependencies.
- Verification: record the checksums or signatures the vendor provides for each artifact and keep them with the change record.
- Plugin sourcing: confirm that plugins are bundled or provisioned from the internal mirror, since some installs fetch them from the internet at startup.
- Patch cadence: patch releases arrive at least monthly, so set a transfer cadence that keeps the environment on supported releases.
Confirm with the security team the approved transfer process and who signs off on each artifact, and check that data source packages are mirrored too.
What the client needs to provide
Before a Grafana upgrade or support engagement starts, the client has to hand over access and evidence that let the team work safely on the running system. The minimum is read access for assessment and admin access for changes to the Grafana servers, the configuration file (grafana.ini or environment overrides), and the provisioning directories that hold data sources, dashboards, plugins and alerting resources. Confirm which of these live on files you control and which are only edited through the UI, because UI edits that were never exported will not survive a rebuild.
The team also needs the database backend and access sufficient to verify backups. Confirm whether the instance runs on SQLite, MySQL or PostgreSQL, since SQLite is not suitable for production or high availability and the upgrade path differs. Provide an inventory of data sources and plugins with their versions, and a named owner for dashboards and alert rules who can confirm which ones matter. Backup and restore evidence should show that a recent backup was actually restored somewhere, not only that a job ran.
The client also owns several decisions that shape every upgrade. These include the target version, the change windows, the rollback thresholds (for example, what error rate or alert behavior triggers a return to the previous release), the support hours and the escalation contacts. A change calendar, an approval path and access to a test or staging environment that resembles production are needed too. Agree the acceptance criteria in writing before the first upgrade so that sign-off does not turn into a debate afterward.
Frequently asked questions
How often does Grafana need to be upgraded?
Plan for a major release once a year, a minor release every other month and patch releases at least monthly. Grafana's upgrade guidance says each minor release is supported for 9 months, and the last minor release of a major version for 15 months. These windows matter because a version past its support end no longer receives fixes, including security fixes. The practical rule is to apply patches promptly, move to a supported minor release within its window, and treat each major upgrade as a planned project with its own testing period.
Can our own team run Grafana minor and patch upgrades?
Often yes, if the team has a staging copy, a tested backup and a rollback path. Minor and patch releases usually change less, so they suit an in-house routine: back up the database, read the release notes, upgrade staging, check dashboards, alerts and data sources, then promote to production. Confirm each step against the upgrade guide for your installation method, whether packages, Docker images or Helm charts. Enterprise installations need the same routine plus license and feature checks. DeployOpen can set up this routine as a one-off or run it under a retainer if your team lacks capacity.
What makes a major Grafana upgrade harder than a minor one?
A major upgrade can include breaking changes, so the work shifts from routine patching to a compatibility review. The team checks removed or changed settings, deprecated features, provisioning files, alert rules, data source behavior and plugin support against the target version's release notes. Dashboards and queries are then retested, and plugins may need updating or replacing before cutover. Enterprise-only features such as SAML, team sync and SCIM also need validation. The effort depends on how much your instance uses features that changed, so confirm the scope of each major upgrade in writing before work starts.
How are Grafana plugins checked for compatibility before an upgrade?
Each installed plugin is inventoried, its declared compatibility with the target Grafana version is checked, and the plugin is tested in staging before production. Plugins are maintained separately from core Grafana, so a plugin can lag behind a release and block an upgrade. Plugins that are unmaintained or no longer compatible need a decision: update, replace or remove. Ask how plugin versions are pinned and recorded, who approves plugin changes, and whether plugin review is part of your written scope.
What does Grafana support cost, and what does a retainer cover?
A one-off upgrade covers a defined change with agreed deliverables and an end point. A retainer covers ongoing work over a period, such as tracking releases, applying minor and patch upgrades, reviewing security patch releases and handling plugin compatibility, as agreed in writing. Costs cover setup, which is one-time, and retainer or upgrade work, which recurs. The main drivers are the number of instances, data sources, dashboards, alerts, plugins, environments, database setup and high availability. DeployOpen does not publish prices, and a quote follows from the written scope. Ask for named deliverables, exclusions, release cadence and change handling.
How long does a Grafana upgrade take, and what must we provide?
The duration follows from the written scope, including the number of instances, data sources, dashboards, alerts, plugins and environments, and whether the change is minor or major. No duration is given here. To prepare, provide access to the current installation and configuration, a staging environment or permission to build one, the database type and version, a plugin and data source list, provisioning files, a current backup, named approvers and an agreed change window. Missing inventory is a common reason timelines change, so share these early.
How DeployOpen scopes and supports Grafana
DeployOpen plans, implements, upgrades and supports self-hosted Grafana inside infrastructure you control, from a written scope agreed before work starts. Upgrades and support are handled as planned change, with testing and documentation at each step.
How we scope
- Inventory your current Grafana version, installed plugins, data sources and the database backing configuration before agreeing on an upgrade path.
- Map the minor and major releases between your version and the target, with breaking changes and plugin compatibility checked for each step.
- Agree in writing which environments, upgrade windows, support hours and response expectations the engagement covers, since most engagements are fixed-scope.
How we build
- Rehearse each upgrade in a non-production copy of your instance, including a restored copy of the configuration database and representative dashboards and alerts.
- Review plugin and provisioning changes against the new release, and update YAML or JSON provisioning files so configuration survives the upgrade.
- Apply security patch releases on a documented cadence, confirm the hardening settings still hold, and record the results of each test run.
How we hand over
- Deliver a runbook covering the upgrade procedure, rollback steps, backup and restore checks, and the version and support-window calendar for your instance.
- Document plugin inventory, compatibility notes and any local changes so your team can review them during future releases.
- Walk your operators through the upgrade process and confirm they can carry out a patch release using the documentation alone.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped to the releases and environments you name in writing.
- Plan upgrades ahead of end of support, since each minor release is supported for a limited window and the last minor of a major for longer.
- Confirm with your team the scope of retainer work, including who monitors release notices and who approves changes before they reach production.
