Prometheus v3.13.3 was published on 7 September 2026 as a stable patch. The change that matters on a busy node is a TSDB fix: out of order queries could block compaction for hours, and memory usage grew for as long as compaction stayed blocked.
The full release notes and downloads are on the GitHub release page.
TSDB compaction, deleted series, and failed opens ¶
Out of order queries could stall compaction for hours. Compaction is what folds head blocks into the on disk TSDB layout. When it cannot run, those blocks stay resident and RSS climbs. The notes do not name a config key or a query shape. Any node that answers queries against out of order data is in the blast radius. The hang lasted hours, not seconds, so this is an incident class bug, not a brief blip on a graph. #19013.
Deleted series could then go missing after a restart, or produce errors on read. Tombstones and deletes are supposed to survive a bounce. If they do not, recording rules and dashboards that look back across the restart window undercount, and the process can error on series that should still exist. That is a correctness bug. #19140.
A third TSDB fix closes goroutine and file handle leaks when Prometheus fails to open a corrupt TSDB. On Windows the leaked directory handle also blocked removal of the TSDB directory, so a failed start left a data dir you could not delete. Linux still leaked goroutines and FDs on the same failed open. If you already have a recovery playbook that wipes a bad data dir and starts clean, test that path on this tag, especially on Windows. #18291.
Scrape and alerting hang the process on shutdown ¶
The scrape manager could spin at 100% CPU on shutdown. #19149. Alerting had the same failure mode: 100% CPU on the way out, graceful shutdown delayed, then a timeout based kill. #17859.
The operator visible symptom is a process that received SIGTERM, pegged a core, and never exited. Supervisors then hit their stop timeout and send SIGKILL. A hard kill skips whatever the process still had to flush. The next start has to recover from that, and you get a noisy restart instead of a clean stop. The notes treat scrape and alerting as two separate loops with the same shape. If shutdown already takes longer than your orchestrator allows, this tag is the one to try.
Neither fix changes scrape config or alertmanager wiring. They close busy loops that should have been waiting for shutdown, not burning a core until someone timed out the process.
PromQL regex matchers and Docker Swarm panics ¶
Case insensitive regex label matchers could drop values that actually matched. #19167. The matcher did not error. It returned a partial set. Recording rules, alerts, and ad hoc queries that use case insensitive regex on labels would undercount and not tell you why. If a dashboard went quiet for some series but not others, and those series differ only by label case, look at this bug before you rewrite the query.
Docker Swarm service discovery panicked when a service ran as a plugin or as a network-attachment. #19102. A panic in the SD loop is not a skipped target. It is a crash in discovery, and the rest of that discovery run dies with it. Clusters that mix normal Swarm services with plugin or attachment tasks were the trigger. The notes do not mention other Docker SD modes. If Swarm discovery is in your scrape_configs, this is the patch that stops a plugin task from taking the loop down.
Go module security pins ¶
The project bumped github.com/klauspost/compress to v1.18.7 for GO-2026-5841 and golang.org/x/crypto to v0.55.0 for GO-2026-6303.
These are module pins, not Prometheus feature work. Compress is the library Prometheus already uses for snappy and zstd. golang.org/x/crypto is the standard Go cryptography module. The notes do not describe an in tree exploit, a new flag, or a config change. Image scanners and govulncheck will look for those two IDs. After this tag they should clear for this tree.
No breaking changes are listed. No migration steps are listed. Treat v3.13.3 as a drop in patch.