What upgrades and support cover for Prometheus
Prometheus is licensed under Apache-2.0 and has no paid edition, so the recurring work on a deployment is keeping the version current, testing each change, and running the service. Ongoing support pays for that work, and the license fee was never the cost. Before you agree on a support arrangement, confirm which release track you are on, who approves upgrades in your change process, and who is on call when a rule or storage change misbehaves after a release. Prometheus ships on two tracks. A new minor release cycle begins every six weeks, and a minor release generally stops receiving bug fixes after those six weeks, so a team that stays on minor releases must upgrade roughly every six weeks to keep receiving fixes. The long-term support line receives bug fixes for one year. The current LTS line is 3.13, released July 1, 2026 and supported until July 31, 2027. LTS 3.5 reached end of life on July 31, 2026, so any deployment still on it has no further fixes and needs a planned move.
Upgrade testing is where most of the risk sits. Before a version change, run your alerting and recording rules against the new release, check that PromQL results still match what dashboards and on-call runbooks expect, and confirm that scrape configuration, relabeling and service discovery still select the same targets. Storage needs its own check, because the local time series database is single-node and a failed upgrade can leave you with no recent history to query. Teams with an internal platform group often keep routine patch upgrades in house and bring in a partner for the risky moves and the support cover. Common triggers are an end-of-life deadline, a security advisory that needs a fast patch, a failed upgrade that must be recovered, or a stack with no one who owns it. Ask for a written scope that names which upgrades, rule tests and on-call hours are included.
What the engagement includes
Each card covers one part of the upgrade and support work. Scope, deliverables and timelines are agreed in writing before work starts.
Release tracking and version policy
A new Prometheus minor release cycle begins every 6 weeks, and a minor release generally stops receiving bug fixes after those 6 weeks. LTS releases receive bug fixes for one year. The current LTS line is 3.13, supported until July 31, 2027. Agree in writing which line you run, who tracks releases and how quickly patches are applied.
Upgrade assessment and config migration
Compare your running version with the target and list every flag, configuration field and behavior change between them. Identify removed or renamed settings, deprecated features and rule syntax that must change before cutover. The output is a dated change list the team reviews, so the upgrade does not depend on one engineer's memory.
Replay test environment with rollback rehearsal
Build a test environment that runs copies of your production scrape configs, recording and alerting rules and a representative storage load. Replay the upgrade there and compare rule results, series counts and query output with the current version. Rehearse rollback too, and confirm which downgrade paths the release notes support before you rely on one.
Companion versions and alert delivery checks
Alertmanager and exporters often need to move with Prometheus, so each pairing is confirmed against the release notes before the change window. After cutover, check dashboards against expected values and send test alerts through every receiver, including routing trees and silences. Confirm that each test page reaches the on-call channel.
Runbook and change records
The runbook covers routine checks, reload and restart steps, backup and restore, and upgrade and rollback procedures, with named contacts for escalation. Change records hold the version history, assessment, test results and sign-offs. DeployOpen does not issue audit reports, so these records are evidence you can give your own auditor, not a certification.
Support arrangement options
Support arrangements define response windows, support hours, patch cadence and on-call escalation paths for the service. Options differ in coverage, and the actual terms are set in the written scope, with no published SLA applying. Before comparing options, ask for each one's response windows, hours, patch timing, escalation contacts and exclusions.
What drives cost and duration
Each row names a factor that changes how much work an upgrade or ongoing support arrangement takes, why it matters for Prometheus, and how to keep it contained.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of Prometheus servers and federation tiers | Every server carries its own configuration, targets, retention and upgrade step. Federation chains add ordering dependencies, so one upgrade can affect several tiers. | Keep the topology as flat as the scale allows. Upgrade one tier at a time in a fixed order and document it in the runbook. |
| Count of rule files and alerts | Recording and alerting rules are parsed by each new version and can change behavior with function or label changes. Test effort grows with every rule that pages someone. | Group rules by owning team, remove unused alerts before the upgrade, and keep a versioned replay set to compare outputs before and after. |
| Remote write or remote read to external storage | The receiving store has its own version, compatibility and retention rules. Changes on either side can cause dropped samples or query gaps that only show up after cutover. | Confirm supported protocol versions with the storage vendor, test writes and reads in staging, and monitor send queue health during the upgrade window. |
| Exporters and custom code that depend on internal APIs | Custom exporters, relabeling tools and scripts that use undocumented internals may break between minor versions. Each dependency needs its own test and sometimes a code change. | Use only the public exporter and client library interfaces where possible. Inventory custom components and assign an owner for each one. |
| Alertmanager clustering | A clustered Alertmanager must be upgraded with its peers in a compatible sequence. Mixed versions or broken gossip can duplicate or suppress notifications. | Confirm the version compatibility guidance for the cluster, upgrade members in sequence, and verify notification delivery to each receiver afterward. |
| Number of environments | Each environment needs its own upgrade run, test evidence and sign-off. Drift between development, staging and production multiplies effort and hides problems. | Keep environments built from the same configuration management code, and promote the same artifact version through each one. |
| Upgrade crossing an LTS boundary or a long gap of minor versions | Minor releases generally stop receiving fixes six weeks after release, so a long gap means more deprecations and config changes to review at once. Moving between LTS lines needs a planned end date for the old line. | Upgrade on a regular cadence within the supported line, track release notes for each intervening version, and plan LTS moves before the current line reaches end of life. |
| Kubernetes operator or Helm-based deployment | Operator or chart upgrades can change generated configuration, CRDs and default settings in addition to the Prometheus binary. Chart version and application version must be tracked separately. | Pin chart and operator versions, diff rendered manifests before applying, and record which chart version maps to which Prometheus version. |
| Air-gapped delivery of binaries and images | Each release must be mirrored into an internal registry or artifact store, and dependencies such as exporters and base images must be transferred too. Transfer and scanning steps add lead time. | Maintain an internal mirror with a defined intake process, list every image and binary per release, and schedule transfers ahead of planned upgrade windows. |
| Compliance evidence requests | Assessors may ask for change records, test results, version inventories and proof of patch timing. Collecting this after the fact takes more effort than capturing it during each upgrade. | Agree the evidence list before the first upgrade, store test outputs and approvals with each change record, and keep a current version inventory. DeployOpen prepares evidence; auditors and certification bodies assess it. |
How an upgrade or support engagement runs
The sequence moves a Prometheus server from its current version to a chosen target with tested rules, storage and a rollback path, then hands it to a support arrangement.
Inventory the current deployment
We record the running Prometheus version, startup flags, rule files, scrape and service discovery configuration, local storage size and retention settings, and every remote write target. Your team confirms which alerts page people and which dashboards depend on them. The step closes with a written inventory that both sides sign off, so the upgrade has a known baseline.
Select the target version
We compare the installed version against the release cycle, which starts a new minor release every 6 weeks, and the long-term support line, which receives bug fixes for one year. We recommend a target on the minor or LTS track and check its end-of-support date against your planning horizon. The output is a short decision record naming the target version, the reason, and the date support ends for the chosen line.
Upgrade staging and diff rules and storage
We rebuild a staging instance from a copy of the production configuration and upgrade it to the target version. We diff rule evaluation results, metric names and label sets, and storage behavior against the current version, and we review any deprecated flags or changed defaults. The step ends with a diff report listing every rule or series change, and your team accepts or rejects each one before production is touched.
Agree the cutover and rollback plan
We write the change plan with the exact order of steps, the window your team approves, and the rollback path. The rollback covers a saved copy of the TSDB data directory, the previous binary, and the previous configuration and rule files, with a test that restores them on staging. The output is an approved change record that names who runs each step and who can call a rollback.
Run the production upgrade and post-change checks
We apply the approved change to production and watch the restart, then run the post-change checks. These confirm that every expected scrape target is up, that rule groups evaluate without errors, and that test alerts travel through Prometheus to Alertmanager and reach each receiver. The step closes when the checklist is signed off with timestamps and the results are saved to the change record.
Hand over into the support arrangement
We transfer the inventory, change record, runbooks and rollback procedure to your team and to the support arrangement if you have one. The support scope, response paths and upgrade cadence are written down, including which release track the server follows next. The handover is complete when your named owners confirm they can run the checks and the rollback without us.
What usually goes wrong
Most Prometheus upgrade problems come from version timing, untested rule behavior, single-node storage, configuration drift and settings that reopen after a change. Each card names the check that prevents it.
Running past the support window
Prometheus minor releases generally stop receiving bug fixes six weeks after they start their cycle, and exporters and Alertmanager follow their own release lines. Upgrading onto a minor that is already outside its window, or leaving exporters and Alertmanager on old versions, leaves known fixes out of reach. Prevention: pick a current minor or the LTS line, such as 3.13, and confirm the support status of every component before you set target versions.
Rule changes that shift alert behavior
PromQL semantics and rule handling can change between versions, so an alert may fire more or less often without any error in the logs. A rule file that loads cleanly does not prove the alerts still behave the same. Prevention: replay existing rules against recorded or staging data on the target version, then compare which alerts fire and when before cutover.
Storage damage after a rollback
Local storage is single-node and unreplicated, so the data directory on that server holds the only copy of recent samples. Rolling back a failed upgrade does not undo changes made to that directory by the new version. Prevention: back up or snapshot the storage path before the upgrade, and confirm in the release notes whether a downgrade of the target version is supported.
Flag and config changes that block restart
Flags get renamed or removed between releases, and a configuration that loaded before can fail validation afterward. The service then refuses to start, often during a maintenance window. Prevention: list changed flags and deprecated fields from the release notes, validate the configuration against the target version in staging with promtool, and keep the previous configuration under version control for a fast revert.
Alerts that go quiet during the window
A receiver, route or silence changed during the upgrade can stop notifications while Prometheus keeps evaluating rules normally. Engineers then see no alerts and may assume the system is healthy. Prevention: freeze routing and silence changes for the window, confirm Prometheus points at every Alertmanager instance, and send a test alert through each receiver after cutover.
Security settings that reopen after upgrade
Redeployments and config rewrites can change web settings that were locked down earlier. Admin APIs must stay disabled unless needed, and the lifecycle endpoint should be off or restricted. Exporters such as SNMP and Blackbox take targets from URL parameters, so anyone with HTTP access can make them send requests. Prevention: recheck these settings and TLS and authentication on every endpoint after each upgrade.
Recurring costs after go-live
This table lists the recurring and periodic cost components of running Prometheus after go-live, who is paid for each, and what to ask for in a support proposal.
| Cost component | Recurring or periodic | What drives it and what to ask for |
|---|---|---|
| Test and staging copies | Recurring | Compute and disk to run copies that mirror production rules and scrape configuration. Ask which upgrades are tested there before production. |
| Storage growth and retention | Recurring | Disk use grows with series count, scrape interval and retention, which defaults to 15 days. Review size limits each quarter. |
| Support hours or retainer fees | Recurring or periodic | Set by the written scope. Ask for response windows, patch scope, covered versions and exclusions. |
| Internal on-call and upgrade time | Recurring | Staff time for alert response, dashboard upkeep and upgrades on the 6-week minor cycle or the LTS line. Scope this to your team's capacity. |
| Waiting on an end-of-life version | Periodic | Minor releases generally stop receiving bug fixes after six weeks. Delayed upgrades create larger, riskier jumps later. |
| Long-term storage behind remote write | Recurring | Billed by the external store on ingested and retained samples. Confirm pricing and retention terms with that vendor. |
| Security and dependency review | Periodic | Time to review new Prometheus releases, exporter versions and TLS or authentication settings. Confirm who owns this in the support scope. |
How the work changes by starting point
A single Prometheus server already on a recent minor release is the simplest starting point. The work is mostly a controlled step to the next supported line, with a focus on configuration and rules rather than data.
- Assessment: Confirm the current version against the release cycle page, check the changelog for every minor release in between, and list deprecated flags or configuration fields in use.
- Testing: Validate rule files with promtool, run the new binary against a copy of the configuration and a snapshot of the data directory, and compare query results for key dashboards.
- Rollback: Keep the previous binary and a data directory backup, since downgrading a TSDB after a newer version has written to it is not something to assume is safe. Confirm this with the vendor.
- Confirm with the vendor: Whether the target version changes any storage format or requires a specific rollback path.
- Confirm in your environment: The maintenance window, who approves the change, and which alerts must keep firing during the restart.
An older release that is out of support, or a move from a minor line onto the LTS line, usually needs several steps. Each step has its own compatibility check, so the plan is a sequence rather than a single jump.
- Assessment: Identify which minor versions are skipped, and review each intermediate changelog for removed features, renamed metrics and changed defaults that affect alerts.
- Testing: Run each intermediate step in a non-production environment, and check rules that reference renamed or removed metrics before any production change.
- Rollback: Define a rollback point before each step, and treat the final LTS target as the baseline you will need to support for about a year of bug fixes.
- Confirm with the vendor: The support dates for your current line and the LTS line you intend to adopt, and whether the path you plan skips any release with a required migration.
- Confirm in your environment: Which dashboards, alerts and exporters depend on version-specific behavior, and who signs off on each intermediate step.
On Kubernetes, the workload is often declared by an operator or a Helm chart, so the upgrade touches chart values, custom resources and the image tag together. Rollback depends on how the operator reconciles state.
- Assessment: Compare the chart or operator version with the Prometheus version it deploys, and review custom resource schema changes, since these can break on upgrade.
- Testing: Render the chart or manifests in a staging cluster, diff the output against production, and confirm that ServiceMonitor, PrometheusRule and Alertmanager resources still reconcile.
- Rollback: Roll back the release through Helm or the operator, but check whether storage volumes, persistent claims or CRD changes survive a downgrade. Restore from volume snapshots when they exist.
- Confirm with the vendor: Which chart or operator version pairs with the target Prometheus release, and whether CRDs must be applied before the chart upgrade.
- Confirm in your environment: Your cluster upgrade schedule, admission policies that may block new resources, and whether Prometheus is scheduled alongside a cluster upgrade.
In an air-gapped environment, every binary, container image and chart must be obtained outside the network, verified, and then moved in. The upgrade cannot pull from public registries during the change window.
- Assessment: List every artifact the upgrade needs, including the server, Alertmanager, exporters, images and any plugins, and check the release notes for new dependencies.
- Testing: Verify checksums and signatures for each artifact against the published release, then test the transfer and loading process in a staging enclave that mirrors production.
- Rollback: Keep the prior artifacts in the mirror and in local storage, so a rollback does not depend on network access.
- Confirm with the vendor: Where official checksums and signing keys are published for each release, and whether the release has a supported container image format you can load offline.
- Confirm in your environment: Your transfer approval process, the internal mirror location, and who verifies artifacts before they cross the boundary.
When Prometheus sends samples through remote write, the storage system is part of the upgrade. A change to either side can cause dropped samples or gaps that only show up later in queries.
- Assessment: Confirm the remote write protocol version and any changes in the target release, and review the receiving store's version support and upgrade notes.
- Testing: Upgrade the storage side in staging first where possible, then confirm that samples arrive, that queue metrics stay healthy and that long-range queries return expected results.
- Rollback: Watch the remote write queue and failed sample counters during the change, and keep the ability to revert the Prometheus side independently of the store.
- Confirm with the vendor: Whether the storage product and the target Prometheus release have a documented compatibility matrix, and which side should be upgraded first.
- Confirm in your environment: Who owns the long-term store, how gaps in retained data will be reported to teams, and how long you must keep the buffered samples during any interruption.
What the client needs to provide
A quote for Prometheus upgrades and support depends on what is already running, so the first request is a current inventory. Send the Prometheus and Alertmanager versions in use, and how each was installed (operating system package, container image, Helm chart, or binary). Include the configuration and rule files, ideally in version control, along with the storage and retention settings: local retention by time or size, the data directory's disk size, and whether remote write is enabled. Attach an exporter list with each exporter's name and version, and note which targets use TLS or basic authentication.
Next, supply the environment details that govern how risky an upgrade is. That means a test environment that mirrors production closely enough to exercise rules and storage, or written permission for us to build one. It also means access to staging and production, the change windows your organization allows, and any freeze periods. Confirm whether Alertmanager runs as a cluster, because that changes the rollout order. Your team should also name the owners of each alert and receiver, since someone must judge whether a rule still fires correctly after an upgrade.
Decide the target track before the quote is written. Choose the 6-week minor cycle, which stops receiving bug fixes once its six weeks end, or the one-year LTS line, and state how much support time you expect each month or year. Ask us to confirm the current LTS line and its end-of-life date against the Prometheus release cycle page at the time of scoping, because those dates move.
Common questions about Prometheus upgrades and support
Should we stay on the 6-week minor releases or move to the LTS line?
Stay on the minor cycle only if you can upgrade about every six weeks. A minor release generally stops receiving bug fixes six weeks after it ships. The LTS line suits most regulated teams that want fewer upgrades, because LTS releases receive bug fixes for one year. The current LTS line is 3.13, released July 1, 2026 and supported until July 31, 2027. Before you choose, confirm your change-window policy and when the next LTS line is due, since an LTS line still needs planned patch upgrades within its support year.
What drives the cost of a Prometheus upgrade?
The cost follows the amount of change and testing the upgrade needs. Prometheus itself has no license fee, so the quote covers labor and test environments. The main drivers are the number of Prometheus servers, Alertmanager instances, exporters and remote write endpoints involved, how many recording and alerting rules must be checked against the new release, whether dashboards, relabeling or SSO proxies need changes, and how much backup verification your change process requires. Ask for line items for inventory, test plan, rollout, rollback rehearsal and handover, and state which items recur under a retainer.
How long does a Prometheus upgrade take in practice?
Your environment decides the duration, so no fixed timeline applies across deployments. The main factors are the number of Prometheus and Alertmanager instances, how many rules and integrations must be retested, how large the storage is and how long a verified backup takes, and the production change windows you allow. Timelines also depend on what you supply: an up-to-date inventory, a staging copy that resembles production, named owners for rules and dashboards, and a person who approves production changes. Ask for a written schedule that lists environments, approval gates and the production window.
Can our internal team upgrade Prometheus without outside help?
Yes, a team with Linux operations and configuration management experience can often upgrade a small deployment alone. It needs a staging copy, a tested rollback and people who can read release notes for breaking changes. The skills that matter most are PromQL for checking rules, Linux service and TLS administration, YAML configuration and relabeling. Teams often find the sustained work harder than a single upgrade, especially on the six-week minor line where each release needs review. Be careful if no one owns the rules, dashboards or alert routing, because those can break without an obvious error.
What does a support retainer cover compared with a fixed-scope upgrade?
A fixed-scope upgrade covers a named set of servers, rules and environments, delivered once against a written plan. A support retainer covers ongoing work over a period, such as tracking releases, planning and running upgrades and continuous testing. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Choose a retainer if you expect the minor cycle to keep the team busy, and fixed scope for one planned move to a new line. Ask for response expectations in writing, since the agreed scope determines them.
Can we roll back a Prometheus upgrade if it fails?
Yes, but plan rollback as a restore from a copy taken before the upgrade. Stop Prometheus, copy the data directory, and keep the previous binary and configuration. Then check the release notes for both versions to see whether the older binary can read the newer storage format. Local storage is a single-node database with no replication, so without a copy a failed upgrade can cost recent data or the full history. Samples written after the copy are lost when you restore it. If you use remote write, the external store may hold newer samples, so confirm what it received.
How DeployOpen scopes, delivers and supports Prometheus
DeployOpen plans and carries out Prometheus upgrades and ongoing support inside infrastructure you control, starting from a written scope that names the release line, the rules and storage to be tested, and who responds after go-live. Engagements are fixed-scope, and support can continue as a retainer.
How we scope
- Confirm the current Prometheus version, whether you run the 6-week minor line or the one-year LTS line, and the target release.
- Inventory alerting rules, recording rules, remote write targets, Alertmanager instances and exporters that each upgrade must be tested against.
- Record in the written scope which upgrade steps, test environments and support hours are included, and which are excluded.
How we build
- Stage the upgrade in a non-production copy with representative scrape targets, rule files and a copy of the local TSDB state.
- Check rules and storage behavior after the change, including PromQL output, retention settings, WAL replay and remote write delivery.
- Document rollback steps and the exact configuration changes so the upgrade can be repeated on each release in your cycle.
How we hand over
- Deliver a runbook covering the upgrade procedure, pre-checks, verification queries and rollback for your environment.
- Walk your platform and on-call teams through the release cycle, including when a minor release stops receiving bug fixes.
- Provide a record of versions deployed, test results and open items so your team can plan the next upgrade without us.
How we support
- Review new Prometheus releases on your chosen line and recommend when to schedule the next upgrade window.
- Apply and test upgrades on your schedule, with support covering the change window as defined in the written agreement.
- Offer ongoing support as a retainer, with the response expectations, coverage and included upgrades stated in the agreement before work starts.
