Prometheus 3.14.0 shipped on August 17, 2026, and while point releases rarely make headlines, this one carries two changes that matter more than the version number suggests. Duration expressions are now enabled by default in PromQL—the feature flag is gone—and Oracle Cloud Infrastructure compute instances can be discovered natively. Taken together, the release signals that the project is doing more than maintenance: it is making PromQL easier to read and expanding its footprint in multi-cloud environments at a moment when the broader observability stack is racing toward richer data models.
GA Duration Expressions Move PromQL Toward Readability
PromQL has always been powerful, but it has never been praised for readability. A typical query for a 5-minute rate looks like this:
rate(my_metric[5m])
The [5m] syntax is concise once you know it, but it is also cryptic to newcomers and easy to mistype in larger expressions. With Prometheus 3.14.0, the promql-duration-expr feature flag is gone, which means expressions like step(5m), range(1h), min_of(30s), and max_of(2d) now work out of the box. The UI has also been updated with syntax highlighting, autocompletion, and linting specifically for these duration expressions in range selectors and subqueries.
The practical impact is twofold. First, it lowers the barrier to entry for teams onboarding new engineers who may not yet have internalized PromQL’s terse time-range bracket syntax. Second, it makes complex queries more explicit and self-documenting, which reduces the review surface area for platform teams managing hundreds of recording rules and alerts. The change is not merely cosmetic: explicit duration functions are easier to lint, refactor, and generate programmatically.
Another PromQL change worth noting is the promotion of first_over_time() to stable. Previously gated behind promql-experimental-functions, this function is now available without feature flags, giving operators a reliable way to return the first sample in a range vector. For long-running aggregations and anomaly detection workflows that depend on boundary values, removing the experimental label means fewer deployment surprises.
Oracle Cloud Infrastructure Discovery Arrives
Service discovery in Prometheus has historically leaned heavily on Kubernetes and the major hyperscalers: AWS EC2, Azure VM, and Google Compute Engine have all been supported for years. Prometheus 3.14.0 adds oci_sd_configs, enabling direct discovery of Oracle Cloud Infrastructure compute instances. For organizations running workloads across multiple clouds—or for those standardizing on OCI as part of compliance or cost-optimization strategies—this removes the need for intermediate exporters or custom file-based discovery targets.
The OCI SD integration follows the same pattern as existing discovery mechanisms: it pulls compute metadata via the OCI API and exposes standard __meta_ labels for hostname, region, compartment, and shape. It does not introduce new configuration paradigms, which means teams already fluent in AWS or GCE discovery can adopt it with minimal friction.
This addition is part of a broader trend in cloud-native tooling. As enterprises diversify their cloud footprints for resilience and procurement reasons, the assumption that “one discovery target fits all” no longer holds. Prometheus maintaining parity across providers is a quiet signal that it remains committed to being infrastructure-agnostic.
OTLP and the Interoperability Push
One of the quieter but operationally important changes in 3.14.0 is improved OTLP translation hygiene. When OTLP attribute names collide after Prometheus sanitizes them—for example, k8s.pod.name and k8s_pod_name both becoming k8s_pod_name—Prometheus now emits a warning at scrape time and exposes a prometheus_api_otlp_translation_warnings_total counter labeled by category. Previously, these collisions were silent, which meant dashboards and alerts could silently underreport or misattribute metrics without operators knowing why.
This change matters because OTLP is increasingly the default ingestion path. OpenTelemetry adoption has accelerated across the CNCF ecosystem, and Prometheus is no longer just a standalone metrics system—it is a backend in a broader telemetry pipeline. Clean translation between OTLP and Prometheus label conventions is a prerequisite for organizations running OpenTelemetry Collectors in front of Prometheus without losing data fidelity.
The release also improves histogram handling in OTLP: the remote write V2 protocol now forwards histogram start timestamps, and native histogram scraping saw a roughly 49 percent reduction in parsing allocations. For teams processing high-cardinality histogram data at scale, the combination of lower memory pressure and more accurate timestamp propagation reduces the operational cost of retaining fine-grained latency distributions.
TSDB Reliability Gets Harder
Prometheus’s time-series database has always been battle-tested at scale, but 3.14.0 fixes a cluster of bugs that could cause silent data loss or instability under edge-case conditions. The highlights include:
- A fix for silent data loss and potential crash loops when
stale_series_compaction_thresholdis configured - A fix for out-of-order ingestion causing data loss on restart after block compaction
- Resolution of goroutine and file-handle leaks when opening a corrupt TSDB
- Elimination of deleted series causing missing samples after restart
- Repair of native histogram data corruption after restart
These are not theoretical edge cases. Teams running stateful Prometheus instances on bare metal or long-lived Kubernetes pods with persistent volumes have encountered these exact symptoms. The fixes do not introduce new features, but they remove entire classes of surprise data loss that previously required manual intervention or external WAL replay tooling.
A Thread Through the Noise: Observability Is Maturing, Not Just Growing
Prometheus 3.14.0 is a point release, but it sits at an interesting inflection point for observability infrastructure in the CNCF ecosystem. While Prometheus is polishing query expressiveness and TSDB reliability, two parallel developments are reshaping what “observable” means upstream:
OpenTelemetry recently shipped entity events in spec v1.58.0, introducing a new signal type that models hosts, services, and network topology as a time-aware graph rather than flat metrics and logs. The idea is to close the gap between knowing how systems behave and knowing what systems exist. Entity events carry immutable identities and relationships—depends_on, contains, and so on—embedded directly in OTLP log records, which means Prometheus backends that ingest OTLP will eventually need to reason about structured entity data as well as scalar time series.
At the same time, the CNCF community is actively discussing the developer experience of observability. A recent post from OpenTelemetry community managers emphasized that developers are increasingly asked to instrument their own code, but face pain points around SDK maturity, language coverage gaps, and metric cardinality explosion. The underlying tension is that observability tooling is getting richer at the backend—better queries, better data models—but the instrumentation surface remains uneven across languages and frameworks.
Prometheus 3.14.0 does not solve those developer-side problems directly. What it does do is make the query and storage layers more robust and expressive, which gives the ecosystem room to absorb higher-quality telemetry as instrumentation improves. Duration expressions make alerts and dashboards easier to write accurately. OTLP translation warnings prevent data from being silently dropped at ingestion. TSDB fixes remove classes of data loss that previously required operator intervention. These are foundation-layer improvements that enable everything above them.
Practical Takeaways
For operators already running Prometheus 3.x, upgrading to 3.14.0 should be a low-friction decision. The breaking changes are minimal: the stats query parameter for /api/v1/query and /api/v1/query_range is deprecated for values other than true or all; a handful of Hetzner labels were dropped; and relabel configs now show empty separator and replacement values explicitly. Most upgrades will be drop-in.
For teams writing PromQL, the GA of duration expressions is an immediate win. Review rules and dashboards for opportunities to replace bracket syntax with named duration functions, especially in complex subqueries. The improved UI linting will catch mistakes during authoring rather than at evaluation time.
For multi-cloud and OCI users, native OCI discovery removes one more reason to maintain custom target management scripts. Configure oci_sd_configs with standard compartment and region filters and treat OCI instances as first-class scrape targets.
For teams with OpenTelemetry Collectors forwarding to Prometheus, monitor the new prometheus_api_otlp_translation_warnings_total counter after upgrading. If it increments, investigate attribute name collisions in your collector pipeline before they distort dashboards.
