VictoriaMetrics October 2026 Ecosystem Updates

October is the month for things that go bump in the night, so we spent it making sure you hear about them. VictoriaMetrics Cloud now supports alerting rules for VictoriaLogs and VictoriaTraces deployments, not just metrics.

Elsewhere, vmauth SSO is out of beta and ready for production. vmanomaly learned to spot the one replica acting differently from the rest. We also did some security housekeeping across VictoriaMetrics and vmestimator. No tricks, mostly treats.

This release roundup includes updates for:

• VictoriaMetrics Cloud
• VictoriaMetrics v1.155.0 and v1.154.0
• Anomaly Detection v1.31.1 and v1.31.0
• vmestimator v0.1.18 and v0.1.17

Highlights

• Alerting for logs and traces: you can now set up alerting rules on VictoriaLogs and VictoriaTraces deployments, not only on metrics. Linking a metrics deployment is optional. If you link one, it stores your recording-rule results. If you don’t, alerting rules still work on their own.
• Stream aggregation on single-node deployments: single-node deployments now have stream aggregation. You can find it in a new tab under Advanced settings. You can aggregate data as it is ingested, which cuts storage and query costs.
• Alerting status at a glance: Alertmanager and Alerting rules pages now show one combined health status for alerting. It uses the same badges as deployment status, so you can see quickly whether alerting is healthy.
• Refreshed rule presets: ready-made alerting rule sets have a new integrations page. You can also browse them directly on the Alerting rules settings page, so adding a preset takes fewer clicks.
• VictoriaTraces agent integration (vtagent): a new Helm chart integration for vtagent joins the existing vmagent and vlagent guides. Sending traces to Cloud now works the same way as sending metrics and logs.

Improvements

• Faster onboarding in integrations: if you have no deployment, API key, or access token yet, you can create one right from the integration dropdown.
• Faster cluster updates: changes that don’t touch storage nodes now go through a quicker update path.
• More tuning for single-node: the maxConcurrentInserts flag is now configurable.
• More reliable live tailing: live log tailing keeps connections alive during long sessions.

Fixes

• Storage recommendations are now correct when you switch between GB and TB.
• Adding rule sets from integrations to single-node deployments no longer fails.
• Public integration pages are fixed.
• Recording rule creation for logs and traces deployments is fixed.

• Potential breaking change: in VictoriaMetrics cluster, /admin/tenants requests without start and end query args now return only tenants for the current day, instead of searching the entire retention period. To retrieve all tenants, set start and end so the time range fully covers -retentionPeriod. vmctl calls /admin/tenants under the hood when migrating data, so make sure you run it with both *-filter-time-start and *-filter-time-end params. See the updated URL format for details.
• v1.152.0 remains the most stable version.

Read the changelog

• vmauth Single Sign-On (SSO) ready for production: Single Sign-On is now fully functional and can be recommended for production use.
• Cancels queries when clients disconnect: vmselect and single-node VictoriaMetrics now cancel query requests when the client disconnects and during graceful shutdown. CPU and memory are no longer spent computing results nobody will read.
• Fixes the pure-Go zstd panic introduced in v1.153.0: vmsingle and vmstorage no longer crash with a cannot decompress zstd data... panic on darwin, windows, freebsd, openbsd, linux/arm, linux/ppc64le, linux/386, linux/s390x and -pure builds. The linux/amd64 and linux/arm64 builds weren’t affected. See the v1.153.0 update note for details.
• This release also ships 18 bug and 3 security fixes

Use v1.31.1 or later for peer-group detection with a periodic scheduler. It fixes a v1.31.0 issue that could block initial training and prevent anomaly scores from being produced.

Read the changelog

October added peer-group detection and a dedicated investigation UI. The new model-selection guide helps you choose between this approach and existing univariate and multivariate models, with six ready-to-run recipes.

Three ways to detect unusual behavior in your metrics

Select an image to view it full size.

• Find the unusual replica. The new peer-group model scores each member separately as peers join or leave. The investigation view highlights affected peers and their behavior.
• Tune detection with your own examples. The experimental Tune workflow lets you mark known anomalies or specify an expected anomaly rate, then review and apply suggested settings across univariate, multivariate, and peer-group models.
• Estimate resources before deployment. Experimental sizing tools estimate CPU, memory, disk, and output requirements—or how much inference work fits within a resource budget. Also available through the vmanomaly MCP server v0.5.0. Validate estimates against your workload and allow extra headroom, especially for peer-group models.
• Process more data and investigate results. Inference throughput increased by up to 25% in tested workloads, depending on the model and configuration. The anomaly-score dashboard adds improved statistics, consistent filters, and forecast-disagreement trends.

Read the vmanomaly changelog and the UI v1.10.0 changelog

• Security fixes: this release contains only security updates, with no new features or bug fixes. We recommend upgrading to pick up the latest upstream fixes.
• Upgrades the Go builder to Go 1.27.3: vmestimator is now built with Go 1.27.3 instead of Go 1.27.2, picking up the issues fixed in Go 1.27.3.
• Upgrades the base Docker image to Alpine 3.24.3: The base Docker image moves from Alpine 3.24.2 to 3.24.3 and includes its latest security patches. See the Alpine 3.24.3 release notes for details.

Read the changelog

• Supports hot config reload: vmestimator can now reload its -config file without restarting, so you can change streams without interrupting cardinality estimation. Reloads are triggered by a SIGHUP signal, by a request to the /-/reload endpoint (protected with -reloadAuthKey), or automatically every -configCheckInterval. See the config reload docs for details.
• Adds per-stream minimum cardinality: The new min_cardinality stream config field overrides the global -cardinalityMetrics.minCardinality flag for individual streams. This gives you finer control over which series each stream reports. When the field is unset or 0, the global flag value is used. See the vmestimator docs for configuration details.
• Rejects duplicate stream definitions: vmestimator now validates the config at startup and refuses to start when two streams are effectively identical. This prevents duplicate work and conflicting metrics.
• Simplifies churn calculation: The calculate_churn: true option replaces churn_interval. Churn is always measured over the stream’s own interval, which makes the configuration simpler and the results more consistent.

Read the changelog

We can’t promise a quiet on-call shift. We can promise that if something goes wrong, you’ll find out sooner and figure out why faster. Grab some candy and enjoy the spooky season. We’ll be back next month with more.