Prometheus Support Options: Project LTS, Managed or Independent

Prometheus has no vendor. It is a Cloud Native Computing Foundation project, supported by its community, by the providers of managed Prometheus services, and by independent providers who support the Prometheus you run yourself. The project's own support window is very short, so most production servers are outside it.

What the project supports

The Prometheus release cycle starts a new minor release every six weeks, and after those six weeks a minor release generally no longer receives bug fixes. To give operators something steadier, the project designates long-term support (LTS) versions that receive fixes for one year, overlapping by at least a month.

LTS is narrow by design. It only receives fixes for selected issues with high severity, meaning a CVSS rating of 7.0 or higher, and it excludes unstable and experimental features. At the time of writing Prometheus 3.13 is the supported LTS, to 31 July 2027. Prometheus 3.5 reached end of support on 31 July 2026 and 2.53 on 31 July 2025. A Prometheus 2.x server is unsupported by the project.

None of this is a criticism. Prometheus is a graduated Cloud Native Computing Foundation project under the Linux Foundation, the de facto monitoring system and time series database for Kubernetes and cloud-native infrastructure, and it is open source and free to use. The project builds the software. It does not run your monitoring, and its documentation says as much by pointing users to community channels and to commercial providers for support.

Managed Prometheus

Managed services from the cloud providers and from observability vendors such as Grafana Labs take the storage and scaling problem away and support their own service. They do not support the exporters, recording rules and alerting rules you wrote, and they are priced by the series you send, which makes cardinality a bill as well as a performance problem.

Where independent Prometheus support fits

• Self-managed Prometheus on older versions, including 2.x, while the move to 3.x is planned.
• Cardinality and memory: a label that explodes the series count and gets the server OOM-killed, slow queries, WAL replay that takes an hour after a restart.
• PromQL and dashboards: Prometheus query language expressions that time out, recording rules that should exist and do not, Grafana dashboards that take a minute to display.
• Collection: service discovery that misses targets, scrape intervals and exporters that produce gaps in the time series data.
• Alerting you can trust: Alertmanager routing, silences and inhibition, alerts that fire late or not at all.
• Scale and retention: federation, remote write, Thanos or Mimir, and how long you actually need to keep metrics.
• The monitoring of the monitoring. When Prometheus is down you are blind to everything else, so it deserves the same support discipline as the systems it watches.

AceMQ provides 24/7 Prometheus support with a 15-minute emergency SLA and named senior engineers, alongside Grafana and Alertmanager. Examples: a cardinality OOM remediation and Grafana alerting support.

The Prometheus incidents that actually page people

• Cardinality explosions. A developer adds a label containing a user ID, request path or pod hash, and one metric becomes millions of series. Memory climbs until the kernel kills the server, and it restarts into the same load. Finding the offending metric through the TSDB status page and dropping the label at scrape time is the first hour of most Prometheus engagements.
• WAL replay after a restart. A large server can spend tens of minutes replaying its write-ahead log before it serves queries or evaluates alerts, which means monitoring is down for exactly as long as the incident that caused the restart.
• Alerts that never fired. The rule was correct, but the for duration, a missing scrape, an Alertmanager inhibition or a routing tree that sends the alert to a channel nobody reads meant no page went out. Alerting needs testing the way code does.
• Slow queries and rule evaluation. Dashboards time out and rule groups miss their evaluation interval, so recording rules and alerts lag. Expensive PromQL over long ranges, regex matchers on high-cardinality labels and missing recording rules are the usual causes.
• Running out of single-server headroom. Prometheus is deliberately a single-node system. When one server is no longer enough, the choices are sharding by function, federation, or remote write to Thanos, Mimir or a managed service, and each changes how queries and alerts work.

Moving from Prometheus 2 to Prometheus 3

Prometheus 2.x is unsupported, so this upgrade is on most roadmaps. The project published a migration guide because 3.0 changed defaults and removed long-deprecated flags: some feature flags became standard behaviour, the scrape protocol and content-type handling became stricter, there are changes to how some regular expressions and range selectors evaluate, and the UI was replaced. The TSDB format means a server should pass through a late 2.x release before 3.x, and a downgrade is only possible to specific versions. Before upgrading, run the configuration and rule files through promtool from the new version, test remote write receivers, and check that exporters serve a content type the new scraper accepts.