v2.4 adds log clustering for noise reduction, a trace waterfall view, alert silence windows and grouped notifications, plus pagination performance and multi-tenant fixes.
v2.4 focuses on two problems operators hit every week: too many log lines to read and too many alert notifications to act on. The three headline features — clustering, the waterfall view and alert grouping — each attack a specific point in the incident workflow, from the first "what is flooding the logs" to the last "make the paging stop". Below is the full list.
During a promotion or an incident, one class of error can flood thousands of lines, and paging through them by hand is slow. v2.4 adds log clustering: logs that are structurally similar and differ only in their variables are automatically grouped within a time window, showing one representative line with its occurrence count and first/last timestamps:
[ERROR] Payment timeout for order {orderId} × 328 first 14:02:11
[ERROR] DB connection pool exhausted × 41 first 14:03:02Open any cluster to expand its full detail. Finding "which error class is most common" no longer means eyeballing the screen — you read the cluster counts instead, and the representative line immediately shows the pattern behind the noise.
Under the hood, clustering works by normalizing variable parts (order ids, timestamps, IP addresses) into placeholders, then grouping identical templates. It is the same idea behind production error-grouping tools, applied directly in the log search you already use. Clustering works as a toggle in the search page: it groups on the message template by default and can be scoped to a service or time range just like a normal query, so it slots into whatever investigation you were already running.
The tracing detail page upgrades from a list to a waterfall view. Spans are laid out on a timeline showing start/end times and overlaps, so parent-child waits, serial and parallel execution become obvious at a glance. Long spans are highlighted, and clicking through to logs narrows down the blocking point faster.
This matters most for deep call chains, where a flat list hides the fact that ten child spans are running sequentially rather than in parallel — the waterfall makes that structure visible immediately. Sequential spans are a real optimization clue: they may be parallelizable.
Two features aimed at reducing alert fatigue:
alert:
rule: "payment_error_rate > 1%"
silence:
from: "2026-10-11 02:00"
to: "2026-10-11 04:00"
group:
window: 5mBoth silence windows and grouped notifications are per-rule settings, so you can quiet a release window for one rule while leaving production paging untouched.
The multi-tenant fix is worth calling out: in a shared platform, a notification landing in the wrong tenant is not a cosmetic bug but a data-isolation breach, so all multi-tenant users should upgrade promptly.
If you run a large multi-tenant deployment, plan this upgrade as a priority rather than a routine refresh, because of the cross-tenant notification fix. Single-tenant teams can schedule it with their normal maintenance window. Either way, the new features are all additive and can be adopted one at a time after the upgrade — enable clustering first, add silence windows before your next release, and leave the waterfall view to whoever debugs deep traces.
Upgrading from v2.3 to v2.4 requires only replacing the binary and keeping the existing config — no breaking database changes. After upgrading, run a quick self-check of log search and alerting, and confirm the three new features (clustering, waterfall, silence windows) before routing traffic back. As always, back up your configuration before upgrading; rollback is a matter of restoring the v2.3 binary if anything looks wrong.