ClickHouse adds anomaly detection and scales alerting in Managed ClickStack

Managed ClickStack now offers statistical anomaly detection on query-builder charts, alongside changes designed to handle tens of thousands of alerts. The practical gain is less hand-written alert logic and better tools for finding out what fired, though anomaly detection has limits worth knowing before it becomes your only alarm bell.

ClickHouse Watch analysis

What happened

ClickHouse says users can add anomaly detection directly to existing query-builder charts. It uses z-scores to compare a metric with its own recent history, so services with different normal ranges can share an alert configuration. Users can choose the sensitivity, baseline period and direction of change to monitor, then preview how often the alert would have fired over the previous 24 hours.

The company also describes scheduler changes for large alert collections, including sharding evaluation across workers, batching database writes and moving webhook delivery into a background queue. The alerts interface adds names and tags, more filters, activity charts and expanded evaluation histories. ClickHouse says these improvements are intended to help teams manage large collections, including those moving alert workloads from tools such as Grafana.

Why it matters

A fixed threshold can miss a meaningful change when each service has a different normal range. ClickHouse gives the example of an error rate rising from 0.1% to 0.9%: a 1% threshold would stay quiet, despite the sharp increase. Comparing each service with its own history offers a more useful way to spot that kind of change without maintaining separate thresholds for every service.

There is a catch: a gradual deterioration can become part of the moving baseline, and a sustained problem may eventually stop triggering an alert. ClickHouse says recurring daily and weekly patterns also need different treatment. For persistent limits, the company still recommends static threshold alerts. In other words, the clever new alarm is a useful addition, not a reason to throw away the smoke detector.

Our read

This is a meaningful operational update, not merely a new chart option. The preview gives teams a way to inspect the likely behaviour of an anomaly alert before saving it, while the scheduler and interface changes address the unglamorous work of managing alerts at scale. Start with a non-critical metric, inspect the preview and keep fixed thresholds where a hard limit matters. An alert that looks statistically unusual is not automatically important, and one that stops firing is not automatically good news.

What to watch

• Whether ClickHouse adds support for seasonality, which it says is planned for a later release.
• How anomaly alerts behave on real workloads with gradual changes and recurring patterns.
• Whether the scheduler improvements keep evaluation timely as alert collections grow.

Discussion spark: Would you trust alerts based on each service’s recent history, or keep fixed thresholds as the default for anything important?

not affiliated with or endorsed by ClickHouse