Why a Prometheus 2 to 3 upgrade needs a planned path
Moving from Prometheus 2.x to 3.x is a planned change that runs through the v2.55 stepping stone and a defined set of breaking changes. Teams that treat it as a package swap tend to discover late that scrape targets have stopped ingesting, that PromQL queries return different results, or that Alertmanager no longer accepts the alert payloads their senders depend on. Before you touch a production server, write down what relies on the current version: scrape jobs, recording and alerting rules, Alertmanager routing, Grafana dashboards, exporters, and any remote write consumers. That inventory determines how much of the path you must walk and who needs to be involved.
Timing matters because the release line you are on keeps moving. A new Prometheus minor release cycle begins every six weeks, and after those six weeks a minor release generally no longer receives bug fixes. Long-term support releases receive bug fixes for one year, and LTS 3.5 reached end of life on July 31, 2026, so a team still on that line has no upstream fixes to rely on. A migration that slips by a quarter can leave you running an unpatched build. Ask at the start whether your target version sits on a supported line when the work is scheduled, and agree on a fallback plan if the window moves.
The supported path goes through v2.55 first, so the changes you must handle can be found while the old behavior is still available in the same binary. Confirm the exact target version against the official Prometheus release notes on the day the work is scheduled, because patch releases and the current LTS line change over time. Record the version you start from, the version you move to, and the release notes you checked. Change boards and auditors will ask which documentation the plan followed, and a written record answers that question without reconstruction.
Alertmanager and dashboards are where surprises tend to land. The removal of the Alertmanager v1 API affects any client that still posts alerts through that interface, so check every sender, not only Prometheus itself. Dashboards and alerting rules may depend on regex matchers or on the le label used by histogram buckets, and a query that worked in 2.x can return different series after the change. Assign an owner to each dependent system, define who signs off on query output, and decide how long the old and new stacks can run side by side.
Scrape failures are the change most likely to appear quickly after cutover. Prometheus 3 expects targets to send a Content-Type header that identifies the exposition format, and exporters that omit it can fail to be scraped. Before cutover, run the new version against a staging copy of your targets, read the scrape errors, and list every exporter that needs an upgrade. Ask each exporter owner to confirm the version in use, and schedule those fixes as a separate work item before cutover night so they do not compete with the migration itself.
What changes between Prometheus 2.x and 3.x
This table lists the changes most likely to affect an existing Prometheus 2.x estate on the way to 3.x, with the impact on running systems and the action the team takes for each. Use it as a checklist for the pre-upgrade inventory and pair it with the official release notes. Exact behavior, defaults and flags vary by target 3.x version, so confirm them before scheduling changes.
| Change | Impact on a running estate | Action the team takes |
|---|---|---|
| v2.55 stepping stone | Upgrading directly from older 2.x releases can skip changes and warnings introduced in the stepping release. | Move to v2.55 first, run it with the current configuration, and clear its warnings before moving to 3.x. Confirm the stepping requirement in the release notes. |
| Scrape failures from missing Content-Type headers | Targets whose responses lack an expected Content-Type header can fail scrapes after the upgrade, so their series stop appearing. | Inventory every scrape target and exporter, test each response against the 3.x parser, and fix exporters that send incorrect or missing headers. Confirm the accepted header behavior for the target version. |
| Regex label matcher changes | PromQL regex matchers can select a different set of series, so alerts, recording rules and dashboards may show changed values. | List every regex matcher in rules, dashboards and API clients, then compare query results on the same data before and after the upgrade. Confirm matching semantics in the release notes. |
| le label changes | Histogram bucket label values can be formatted differently, which breaks queries and rules that compare literal le values. | Search for literal le values in queries, rules and dashboards, update them, and check histogram_quantile output against the 2.x baseline. Confirm the formatting change for the target version. |
| UTF-8 metric and label names | 3.x accepts a wider range of metric and label names, so new names can reach downstream tools that expect legacy syntax. | Audit exporter naming, relabeling, remote write consumers and dashboards, then decide whether to keep legacy validation or adopt UTF-8 names. Confirm the related settings in the release notes. |
| Alertmanager v1 API removal | Integrations, scripts or tooling that call the Alertmanager v1 API stop working, which can disrupt alert delivery and silence management. | Confirm which Alertmanager endpoints each client uses, move them to the v2 API, and test notification and silence workflows against a staging Alertmanager. |
Why scrapes and queries break after the move
The first breakage after moving to Prometheus 3 usually shows up as a target that stops reporting, not as an error in the Prometheus process. When a scrape fails, the target's up series drops to 0 and no samples arrive for that job or instance. Start by running up == 0 grouped by job, then open Status and Targets to read the last scrape error for each failing target. A missing or unexpected Content-Type header is one cause to look for in that error text. Check the metrics page of a failing exporter directly with curl and inspect the response headers, since the proxy, load balancer or exporter itself may be responsible for dropping the header.
Exporter versions decide how much of this work lands on your team. Each exporter ships on its own release cycle, so a fleet of node, database and application exporters can be on several different versions at once. Build an inventory that records each exporter's job name, version, host and the protocol its endpoint returns, and compare it against the release notes for the Prometheus 3 line. Test one instance of each exporter type against a 3.x server in staging before cutover. For each exporter, decide whether to upgrade it or to use a Prometheus setting that falls back to the older text format. Confirm which fallback settings exist in your version and whether they apply per job, because a global fallback can hide problems you need to see.
Regex matching is the change most likely to alter query results without any visible error. The release notes describe changes to how regular expressions in label matchers are evaluated, so a pattern written for 2.x may match a different set of series in 3.x. A selector such as =~"api.*" can return fewer or more series, and an alert rule built on it can stop firing or fire on unexpected labels. Nothing in the query fails, so the change only appears in the numbers. Confirm the exact matching rules in the release notes, then list every =~ and !~ matcher used in dashboards, recording rules and alert rules. Evaluate each one on the same data in both versions and compare the series counts and label sets.
Histogram bucket labels deserve the same scrutiny. The le label carries the upper bound of each bucket as a string, and the release notes describe changes to how those values are formatted in the 3.x line. A dashboard that matches le="1" exactly, or a recording rule that stores the le value and later joins on it, can return empty panels or split one bucket into two series. histogram_quantile results can shift when buckets are read under a different label value. To spot this, run count by (le) on a histogram metric in both environments and compare the distinct values. Confirm the formatting rules in the release notes for your exact target version, and treat any mismatch in recording rules as a required change before cutover.
Detecting silent changes needs a process, not a single check. Keep a set of golden queries with expected results taken from the 2.x production environment, and run them against the 3.x instance during a parallel period. Compare result counts and label sets, not only whether a query returns data. Watch rule evaluation health as well, using the rule evaluation metrics your version exposes, and confirm those metric names in the documentation for that release. Assign one owner to sign off each dashboard and alert group, and record the decision for each exporter and matcher in the upgrade plan. Any finding that cannot be explained by the release notes should go back to the vendor or community before the 2.x server is retired.
What to back up and inventory before the upgrade
Most upgrade risk sits in data and configuration that Prometheus does not manage for you. The cards below cover what to back up, catalog and record before you change anything. Build a staging environment with production-like scrape volume so you can test each item under load.
Local time series data and configuration
Local storage keeps the time series database in two-hour blocks with a write-ahead log, and the default retention is 15 days. The Prometheus storage docs state that local storage is not clustered or replicated, so a disk failure loses data unless you copy it deliberately. Back up the data directory from a consistent filesystem copy, along with prometheus.yml, rule files and TLS material. Confirm the backup restores on a test instance before you start the upgrade.
Scrape targets and exporter versions
List every scrape job, service discovery source, static target and exporter, with the version each exporter runs and its scrape interval and timeout. Exporters such as SNMP and Blackbox take targets from URL parameters, so record which clients can reach them. Check that each target sends a Content-Type header, because scrapes from targets that omit it fail after the upgrade. Flag any exporter that needs a version change first.
Recording rules, alerting rules and dashboards
Export every recording and alerting rule file and assign an owner to each rule. Search the expressions for regex matchers and for references to the le label, since the 3.x changes can break queries that use them. Export dashboards too, because each panel carries its own PromQL. Run the same queries against staging and compare the results before and after the change.
Alertmanager configuration and API consumers
Record the Alertmanager configuration, its cluster flags and every instance that Prometheus targets. Prometheus should list each Alertmanager instance individually, with no load balancer in front. Identify every consumer of the Alertmanager API, including webhooks, scripts and tooling, because the removal of the v1 API breaks clients that still call it. Confirm each consumer already uses a supported API version.
Remote write and remote read endpoints
Document each remote write and remote read endpoint, including its URL, authentication, queue settings and the long-term storage system behind it. Data held in remote storage sits outside the local backup, so confirm its retention and recovery separately. After the upgrade in staging, check that samples are still accepted and that remote read queries return the expected series.
Security settings and reverse proxy
Record the admin API and lifecycle flags, since --web.enable-admin-api and --web.enable-lifecycle change which destructive and reload endpoints the server exposes. Note the TLS settings, minimum TLS version, client certificate requirements and any HTTP basic authentication with bcrypt-hashed passwords. Document the reverse proxy in front of the UI and API, including any SSO and headers it adds. Basic authentication without TLS exposes credentials in cleartext.
Choosing the 3.x target and the v2.55 stepping stone
The supported path into 3.x runs through v2.55. Each current 2.x server should move to v2.55 first, and the move to 3.x should be planned as a second change with its own test run and rollback point. Start by recording the exact 2.x version each Prometheus server runs, including any installed from a distribution package or a Helm chart, because those builds often lag the upstream releases. For each server, confirm in the official upgrade documentation that v2.55 is a valid step from your version, and check that the configuration loads on v2.55 without changes you have not reviewed. Local storage is a single node without replication, so take a copy of the data directory or confirm your backup method works before each hop. Treat the step to v2.55 as a release of its own so that any problem is isolated before 3.x begins.
Two release lines matter when you pick the target. The standard minor line starts a new cycle every 6 weeks, and after those 6 weeks a minor release generally no longer receives bug fixes, so a team on this line must plan an upgrade roughly every six weeks to stay supported. The long-term support line receives bug fixes for one year. The current LTS line is 3.13, supported until July 31, 2027. LTS 3.5 reached end of life on July 31, 2026, so any server still on it no longer receives fixes and should be scheduled for upgrade now. To choose a line, ask how often your team can run a full upgrade cycle, including alert rule and dashboard review, and who approves each change.
For most teams running production alerting, the LTS line is the lower-change choice. It gives a predictable yearly move, which suits a team that must re-test alert rules, recording rules and dashboards after each upgrade. A newer minor line brings fixes and features sooner, but it asks for a move about every six weeks. Latest releases on GitHub as of October 2026 included v3.15.0, published September 25, 2026, and LTS patch v3.13.4, published October 2, 2026. Write the decision down with the target version, the date you will review it, and the owner who signs off the test results. Confirm that your team can support the cadence of the line you choose before you commit to it.
Confirm the target on the day you plan the change. Open the official Prometheus GitHub releases page and check the newest patch in your chosen line, along with its publication date and release notes. Versions move, so a number written into a plan weeks earlier may already have a newer patch. Record the version you are installing, the checksum or image digest your team verified, and the release notes you reviewed for breaking changes. If you run an LTS line, also check the release cycle page for the support end date, since a window that closes soon can change when the next move is due. Schedule the 3.x step only after v2.55 has run cleanly in production for a period your team agrees on.
Prometheus 2 to 3 upgrade sequence with checks and rollback points
This sequence moves a Prometheus 2.x deployment to a 3.x release in stages, where each stage has a verification check and a defined rollback point. The team can stop or revert at any step before production is affected. The exact flags and migration commands for each version come from the release notes, which the team must confirm before every stage.
Freeze configuration changes and record the baseline
The platform owner announces a freeze on changes to Prometheus configuration, rule files, Alertmanager settings and dashboards for the duration of the upgrade. The team records the current Prometheus version, the configuration and rule file versions, the active scrape target count, and a list of queries and dashboards that matter to on-call staff. This baseline is what later checks compare against. The step is done when the freeze is documented, the change tool blocks edits to those files, and the baseline has been saved to a location the upgrade team can read.
Back up data, configuration and rules
The operations team takes a consistent copy of the Prometheus data directory, the configuration, all rule files, and the Alertmanager configuration, then stores them outside the host being upgraded. Because local storage is single-node, the team confirms the snapshot method with the storage documentation and checks that the backup can be restored onto a separate host. The verification check is a successful test restore in staging, with the restored instance starting and returning query results for a known time range. This backup is the primary rollback point for every later step.
Upgrade staging to v2.55 first
The team upgrades the staging instance to v2.55, the stepping stone release for this path, using the migration guidance in that version's release notes. They confirm the instance starts cleanly, every scrape target reports healthy or has a known and documented reason for failing, and rule groups evaluate without errors in the logs. The rollback point is the previous binary and configuration, which stay on the host until this stage passes, with the staging backup as the fallback if data is affected. The step is done when a full day of staging metrics matches the baseline queries.
Upgrade staging to the 3.x target
From the verified v2.55 staging instance, the team moves to the 3.x release chosen for the deployment, such as the current LTS line if the organization follows it. The team reads the release notes for that target to confirm the required flags, removed features and migration commands, and applies only the changes listed there. The check is that the instance starts, targets and rules behave as in the baseline, and the logs show no new deprecation or parse errors. Rollback means returning to the v2.55 binary and configuration with the staging backup held in reserve.
Fix scrape and label issues in staging
The team works through the failure classes most often reported in 3.x upgrades: scrape failures from targets that do not send the expected Content-Type header, and queries that break because regex matchers or le label values behave differently. For each affected target or query, the engineer documents the cause, applies the smallest configuration fix confirmed in the release notes, and reruns the check. The step is complete when scrape success rates match the baseline and every query in the baseline list returns results that match the expected values. Each fix is stored in version control so it can be reverted independently.
Move Alertmanager integration off the v1 API
The team updates the Alertmanager configuration so that Prometheus sends alerts through the supported API version, and confirms in the Alertmanager documentation and release notes which API version the target release expects. Prometheus should point at every Alertmanager instance in the cluster, so the check covers each instance individually. The team fires a test alert from a staging rule, then confirms it arrives at the expected receiver and that grouping, inhibition and silences still behave as before. Rollback is restoring the previous Alertmanager configuration from version control.
Validate rules and dashboards against the baseline
The engineering team runs the rule validation tooling for the target release against every rule file, then compares rule outputs and dashboard panels with the baseline recorded at the start. Panels that depend on changed label values or regex behavior are reviewed by the people who use them, not only by the engineer who changed the configuration. The step is done when rule validation passes, panel values match or have approved explanations, and the owners of each dashboard sign off in writing. Failed items return to the fix step, and the staging instance stays on the target release until every item is closed.
Cut over production in a controlled window
The team schedules the production change in a window agreed with the service owners, repeats the staging sequence on production with the same backup and configuration set, and keeps the previous binary and configuration available throughout. Before the change starts, the team confirms the backup restores successfully and that the on-call contacts for the window are named. After the upgrade, they check target health, rule evaluation, alert delivery and the baseline queries. The step closes when all checks pass and the owners accept the result. If any check fails, the team reverts to the previous binary and configuration, or restores the backup if data is affected, as the release notes describe.
How to test queries, alerts and rollback before cutover
The test plan has to show that Prometheus 3.x answers the same questions your teams and alerts ask of 2.x, and that starts with query replay. Collect a representative set of PromQL expressions from dashboards, recording rules and alerting rules, then run them against both versions over the same time window and compare the results sample by sample. Give extra attention to the queries most likely to change: regex label matchers, histogram queries that depend on the le label, and any metric or label names that rely on UTF-8 handling. Sort each difference into one of three groups: expected and documented, a query that needs a change, or a blocker that stops cutover. Record which queries you tested and against which exact versions, because this list becomes the evidence your reviewers will ask for.
Every alerting rule should be executed and checked, and loading it is not enough. Validate the rule files with the checker shipped with your Prometheus release, then force each rule into its firing state using synthetic input or a staging copy of production data. Confirm that each rule fires, resolves and carries the same labels and annotations as before. Pay attention to evaluation errors and to the for durations, since a change in evaluation behavior can make an alert fire early, late or not at all. Next, confirm that Alertmanager receives alerts from the new server, that grouping, inhibition and silences behave as they did, and that each receiver gets the right notification. If you run Alertmanager as a cluster, check that Prometheus lists every instance and that the Alertmanager version accepts the API calls Prometheus makes after the upgrade, since the removal of the v1 API affects this path.
Measure scrape health per target with numbers, using the up series and scrape duration for every job. Build a baseline on the old version over a window long enough to cover your normal traffic pattern, then compare the same measures after cutover. Scrape failures caused by missing Content-Type headers are the change most likely to appear here, so look for targets whose up value drops to zero without an obvious network cause, and inspect their exporter responses. Also confirm that service discovery returns the same targets and that relabeling produces identical job and instance labels, because dashboards and alerts depend on them. Set acceptance thresholds in writing before the window opens, and agree on who signs off each one.
Decide the rollback conditions before the window opens. Rollback is warranted when a blocker from the query or alert tests remains unresolved, when scrape success falls below the threshold you agreed, when Alertmanager stops delivering notifications, or when the new server shows rule evaluation errors or resource use that the baseline did not. Write each trigger with a named owner and a decision time. The restore plan must match what changed: the configuration files and the data directory from a snapshot taken while the old version was still running, plus any remote write queue state you need to reconcile. Whether the older binary can read data written by the newer version is the question that controls the plan. The release notes for your chosen versions state what is supported, and your team must confirm that statement for the exact version pair before the window, not during it.
After cutover, monitor Prometheus as a service in its own right. Scrape the upgraded server from a second Prometheus or another monitoring path, so that a failure in the upgraded server does not also hide its own outage. Watch the server's own metrics for failed scrapes, rule evaluation failures, configuration reload status, growth of the local time series database on disk, and write-ahead log size. Local storage is a single node database and is not replicated, so confirm that the configured retention, which defaults to 15 days, still matches the disk you provide. Keep the admin API disabled unless a task requires it and confirm that the lifecycle endpoints are restricted, since an upgrade is a common moment for configuration drift. Keep the pre-cutover snapshot until the hold period you agreed has ended, and record the final decision in your change log.
What makes a Prometheus 2 to 3 upgrade take longer
This table lists the factors that set how much work a Prometheus 2 to 3 upgrade involves, what each one changes, and what tends to shorten it. Use it to size your own estate before requesting a quote. The drivers set the effort, but your team must confirm the specifics in its own environment, including exporter versions, rule files and downstream consumers.
| Driver | Effect on the upgrade | What reduces it |
|---|---|---|
| Exporters and custom scrape configs | Each job needs checking for scrape protocol behavior, including exporters that omit Content-Type headers, and relabel rules need review. | Inventory every job, pin exporter versions, and test each scrape against a staging server first. |
| Recording and alerting rules | Rules with regex matchers or assumptions about the le label may return different results, so each rule needs a comparison. | Export rule files, run old and new versions side by side, and diff results over a fixed time window. |
| Dashboards and external PromQL consumers | Grafana panels, API clients and reports that query Prometheus can break when label or regex behavior changes. | Catalog query owners, extract queries from dashboards, and test each one before cutover. |
| Alertmanager receivers and automation | Scripts or tools that call the Alertmanager v1 API must move to a supported API before the upgrade. | List every API caller, confirm the version each one uses, and update those clients before upgrading. |
| Remote write and long-term storage | Remote write settings and downstream storage compatibility must be checked, since sender changes affect the receiving system. | Document each remote write target, confirm compatibility with it, and stage changes in a test pipeline. |
| Data size and retention settings | Large local storage can lengthen restart, backup and rollback steps, and retention flags need review. | Confirm retention by time or size, check disk headroom, and take a verified snapshot before starting. |
| High availability pairs | Each replica must be upgraded in turn while alerts keep flowing, and replicas can diverge if one is left behind. | Plan a fixed upgrade order, keep one replica serving, and verify alert delivery after each step. |
| Security configuration | SSO proxies, TLS settings, and admin API and lifecycle flags need retesting because each affects how clients connect. | Record current flags, keep admin APIs disabled unless needed, and retest proxy login and TLS after the change. |
Questions teams ask before a Prometheus 3 upgrade
How much does a Prometheus 2 to 3 upgrade cost?
The software has no license fee, because Prometheus is licensed under Apache-2.0 and there is no paid enterprise edition of the project. Your cost comes from four places: infrastructure, storage, implementation labor and the people who run the system afterward. One-time costs include the inventory, testing of rules and dashboards, and the cutover itself. Recurring costs include hosting, storage growth, on-call time and routine maintenance. The main cost drivers are how many targets, rules, dashboards and downstream integrations you have. When you request a quote, ask for the work itemized by phase, with one-time and recurring costs separated, and with the assumptions and exclusions stated in writing.
How long does a Prometheus 3 upgrade take?
Duration depends mostly on the size and condition of your estate, not on the version number alone. The biggest factors are the number of scrape jobs and targets, how many alert rules and dashboards depend on query behavior, whether you use remote write or Alertmanager clusters, and how many teams must review changes. Estates with clean configuration in version control and named owners move faster than estates where nobody is sure which dashboards are still used. Prometheus also ships minor releases every 6 weeks, so the target version you choose affects how much change you must absorb. Ask any provider for a schedule built from your inventory, with the dependencies and approval points named.
What does our team need to provide for the upgrade?
The work goes faster when your team supplies four things. First, an inventory of Prometheus servers, scrape configurations, recording and alert rules, Alertmanager setup and exporters. Second, access to the hosts, configuration repositories and a staging environment that resembles production. Third, change windows agreed with the operations and business teams that depend on monitoring. Fourth, named owners for each dashboard, alert and receiver who can confirm that behavior is still correct after the upgrade. If owners are missing, the upgrade often stalls at the point where someone must decide whether an alert should still fire, so settle ownership before the build begins.
Can an internal team upgrade Prometheus without a partner?
Yes, many internal teams do this, especially when the estate is small, the configuration is managed in Git and the team already knows PromQL well. The work is mostly careful testing: comparing query results before and after, reviewing scrape health, checking alert behavior and updating anything that depends on changed label or protocol handling. The risks rise when no one has time for the testing, when ownership of alerts is unclear, or when the monitoring data supports audited processes and must be documented as evidence. An honest self-assessment asks whether your team has the hours, the staging capacity and the review discipline for a multi-week effort on top of normal operations.
What does a DeployOpen engagement cover for this upgrade?
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so Prometheus runs in your cloud accounts, data centers or air-gapped network. Most engagements are fixed-scope, which means the scope, deliverables and timeline are agreed in writing before work starts. For an upgrade, the written scope typically defines the inventory and assessment, the compatibility review of queries, rules and integrations, the test plan, the cutover steps and the documentation handed over. Exact deliverables depend on your estate and are set out in the scope document. Ongoing support and upgrades can be arranged as a retainer if you want help beyond the initial change.
How do we ask for a quote from a written scope?
Start by writing down what you want changed, not the price you expect. Send the inventory of servers, scrape jobs, rules, dashboards, receivers and exporters, along with your current and target Prometheus versions, the environments involved and any compliance or change-control constraints. Then ask the provider for a written scope that lists deliverables, assumptions, exclusions, your responsibilities, acceptance criteria and a timeline. A quote should follow from that scope. DeployOpen does not publish a price list, so a quote is produced from the written scope. Compare proposals by checking that they describe the same work, because differences in scope usually explain most differences in price.
What usually breaks during a Prometheus 2 to 3 upgrade?
The most common failures are behavioral changes that look harmless until a dependent system reacts. Scrapes can fail when targets do not send the Content-Type headers that Prometheus 3 expects, which leaves metrics missing rather than producing an obvious error. Queries and alerts can change meaning when regex matching or the handling of le labels differs from what your rules assumed. Some teams also meet UTF-8 metric and label names in places that were not designed for them. Alertmanager's v1 API removal affects any sender still calling it. Before cutover, check scrape health per job, diff query results for critical rules and confirm every alert still reaches its receiver.
Should we target the LTS line or the latest Prometheus release?
For most production estates, the long-term support line is the more predictable target, 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, and LTS 3.5 reached end of life on July 31, 2026. Regular minor releases generally stop receiving bug fixes after 6 weeks, so an estate that runs them must upgrade often. Choose based on your own release policy, your appetite for frequent change and the features you need. Confirm the support dates against the Prometheus release cycle page before you commit, since support windows are set by the project.
How DeployOpen scopes and delivers a Prometheus upgrade
DeployOpen plans and delivers Prometheus 2 to 3 upgrades inside infrastructure you control, starting with a written scope that covers the v2.55 stepping stone, scrape and query compatibility, and Alertmanager API changes. Work runs in stages so each change can be tested against your own targets, rules and dashboards before cutover. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope lists every Prometheus server, exporter, rule file and Alertmanager instance included in the upgrade.
- It names the target 2.x version, the v2.55 stepping stone, and the 3.x line that will be deployed.
- Scope also covers query and label review for regex matchers and le label changes, plus UTF-8 metric name handling.
How we build
- Scrape targets are checked for Content-Type headers so failing endpoints are found before cutover.
- Recording and alerting rules are rewritten and tested against recent production data in a staging copy.
- Alertmanager configuration moves off the removed v1 API and is validated with test alerts and routing checks.
How we hand over
- Handover includes the as-built configuration, upgrade runbook, rollback steps and a record of every query change.
- Dashboards and alert rules are documented with owners, so teams know which panels changed and why.
- Your team receives a walkthrough of the new 3.x operations model before the environment is signed off.
How we support
- Retainers can cover patch releases, LTS line moves and follow-up fixes after the upgrade.
- Support covers the upgrade path for future minor releases, which the project ships on a six-week cycle.
- Post-upgrade issues are triaged against the documented baseline so fixes stay traceable to a known state.
