Skip to main content
Skip to main content
Edit this page

Alerts with ClickStack

ClickStack includes built-in support for alerting, enabling teams to detect and respond to issues in real time across logs, metrics, and traces.

Alerts can be created directly in the HyperDX interface and integrate with popular notification systems like Slack and PagerDuty.

Alerting works seamlessly across your ClickStack data, helping you track system health, catch performance regressions, and monitor key business events.

Types of alerts​

ClickStack supports two complementary ways to create alerts: Search alerts and Dashboard chart alerts. Once the alert is created, it is attached to either the search or the chart.

1. Search alerts​

Search alerts allow you to trigger notifications based on the results of a saved search. They help you detect when specific events or patterns occur more (or less) frequently than expected.

An alert is triggered when the count of matching results within a defined time window either exceeds or falls below a specified threshold.

To create a search alert:

Open alert creation dialog​

Start by entering a search and clicking the Alerts button in the top-right corner of the Search page.

Create the alert​

From the alert creation panel, you can:

  • Assign a name to the saved search associated with the alert.
  • Set a threshold and specify how many times it must be reached within a given period. Thresholds can also be used as upper or lower bounds. The period here will also dictate how often the alert is triggered.
  • Specify a grouped by value. This allows the search to be subject to an aggregation, e.g., ServiceName, thus allowing multiple alerts to be triggered off the same search.
  • Choose a webhook destination for notifications. You can add a new webhook directly from this view. See Adding a webhook for details.

Before saving, ClickStack visualizes the threshold condition so you can confirm it will behave as expected.

Note that multiple alerts can be added to a search. If the above process is repeated, you will see the current alerts as tabs at the top of the edit alert dialog, with each alert assigned a number.

2. Dashboard chart alerts​

Dashboard alerts extend alerting to charts.

You can create a chart-based alert directly from a saved dashboard, powered by full SQL aggregations and ClickHouse functions for advanced calculations.

When a metric crosses a defined threshold, an alert triggers automatically, allowing you to monitor KPIs, latencies, or other key metrics over time.

Note

For an alert to be created for a visualization on a dashboard, the dashboard must be saved.

To add a dashboard alert:

Open the chart edit dialog​

Open the chart's configuration menu and select the alert button. This will show the chart edit dialog.

Add the alert​

Select Add Alert.

Define the alert conditions​

Define the condition (>=, >, <=, <, =, !=, <= x >=, > or <), threshold, duration, and webhook. The duration here will also dictate how often the alert is triggered.

You can add a new webhook directly from this view. See Adding a webhook for details.

Adding a webhook​

During alert creation, you can either use an existing webhook or create one. Once created, the webhook will be available for reuse across other alerts.

A webhook can be created for different service types, including Slack and PagerDuty, as well as generic targets.

For example, consider the alert creation for a chart below. Before specifying the webhook, the user can select Add New Webhook.

This opens the webhook creation dialog, where you can create a new webhook:

A webhook name is required, while descriptions are optional. Other settings that must be completed depend on the service type.

Note that different service types are available between ClickStack Open Source and ClickStack Cloud. See Service type integrations.

Service type integrations​

ClickStack alerts integrate out of the box with the following service types:

  • Slack: send notifications directly to a channel via either a webhook or API.
  • PagerDuty: route incidents for on-call teams via the PagerDuty API.
  • Webhook: connect alerts to any custom system or workflow via a generic webhook.
ClickHouse Cloud only integrations

The Slack API and PagerDuty integrations are only supported in ClickHouse Cloud.

Depending on the service type, you will need to provide different details. Specifically:

Slack (Webhook URL)

  • Webhook URL. For example: https://hooks.slack.com/services/<unique_path>. See the Slack documentation for further details.

Slack (API)

PagerDuty API

Generic

  • Webhook URL
  • Webhook headers (optional)
  • Webhook body (optional). The body currently supports the template variables {{title}}, {{body}}, and {{link}}.

Managing alerts​

Alerts can be centrally managed through the alerts panel on the left-hand side of HyperDX.

From this view, you can see all alerts that have been created and are currently running in ClickStack.

This view also displays the alert evaluation history. Alerts are evaluated on a recurring time interval (defined by the period/duration set during alert creation). During each evaluation, HyperDX queries your data to check whether the alert condition is met:

  • Red bar: The threshold condition was met during this evaluation and the alert fired (notification sent)
  • Green bar: The alert was evaluated but the threshold condition wasn't met (no notification sent)

Each evaluation is independent - the alert checks the data for that time window and fires only if the condition is true at that moment.

In the example above, the first alert has fired on every evaluation, indicating a persistent issue. The second alert shows a resolved issue - it fired twice initially (red bars), then on subsequent evaluations the threshold condition was no longer met (green bars).

Clicking an alert takes you to the chart or search the alert is attached to.

Deleting an alert​

To remove an alert, open the edit dialog for the associated search or chart, then select Remove Alert. In the example below, the Remove Alert button will remove the alert from the chart.

SQL-based chart alerts​

SQL-based chart alerts let you write arbitrary ClickHouse SQL to define alert conditions. This gives you full control over filtering, aggregation, and math — anything you can express in SQL can become an alert.

Supported chart types​

SQL-based alerts are supported on three chart display types:

Chart typeBehavior
LineTime-series alert. The query must produce time-bucketed rows. Each bucket is evaluated independently against the threshold.
Stacked BarTime-series alert. Same behavior as Line.
NumberSingle-value alert. The query returns a single numeric result which is compared against the threshold once per evaluation.

Other SQL-based chart types (Table, Pie, Heatmap, etc.) do not support alerts.

Creating a SQL alert​

To create an alert on a SQL-based chart:

Create or open a SQL-based chart on a dashboard​

From a saved dashboard, either create a new chart with the SQL chart mode, or open an existing SQL-based chart for editing.

Choose Line, Stacked Bar, or Number as the display type.

Add the alert​

Select Add Alert from the alert section of the chart editor. Configure:

  • Threshold type: >= (greater than or equal), > (greater than), <= (less than or equal), < (less than), = (equal), != (not equal), <= x >= (between), or > or < (outside)
  • Threshold value: The numeric value to compare against
  • Interval: How often the alert is evaluated (1m, 5m, 15m, 30m, 1h, 6h, 12h, or 1d). This also defines the time window for each evaluation.
  • Webhook: The notification channel to use when the alert fires. See Adding a webhook.
Alert Time Range

Typically, alert queries are executed once per interval. However, if one or more intervals are skipped due to errors or slow queries, the following execution will use a time range that includes the missed intervals. In this case, the query's interval parameters would still be set to the alert's configured period, but the time range parameters would reflect the longer time range.

Save the dashboard​

Save the dashboard to activate the alert. The alert will begin evaluating on the configured interval.

How query results are interpreted​

The alert system inspects the columns returned by your SQL query to determine what to compare against the threshold.

  • Value column: The last numeric column in your SELECT clause is used as the alert value. If your query returns multiple numeric columns (e.g., count, avg_latency, p99_latency), only the last one (p99_latency) is compared to the threshold.
  • Timestamp column: For time-series charts (Line and Stacked Bar), the system identifies the Date/DateTime column in your results as the time bucket (i.e. the x-axis on a time-series chart). The value column for each time bucket is evaluated against the threshold independently, and if the value for any time bucket breaches the configured threshold, the alert will trigger.
  • Group columns: Any non-numeric, non-timestamp columns (e.g., ServiceName, Environment) are treated as grouping dimensions. When groups are present, each unique combination of group values is tracked and alerted on separately. ClickStack will send an alert for each group with a value that breaches the configured threshold. Groups are only available for time-series charts.

Query parameters and macros​

SQL alert queries support template parameters and macros that are automatically replaced at evaluation time. These are the same parameters and macros available when building a SQL-based chart.

Required and Recommended Parameters​

Queries used for line or stacked bar chart alerts must include an interval parameter or macro ({intervalSeconds:Int64}, {intervalMilliseconds:Int64}, $__timeInterval(col), or $__timeInterval_ms(col)). During alert execution, it will be replaced with the alert's configured period.

Queries used for alerts should include a time range filter ({startDateMilliseconds:Int64} and {endDateMilliseconds:Int64}, or $__timeFilter(col), etc.). Regardless of whether a time range filter is present in the query, the alert query will run on the alert's configured period. If there is no time range filter, then the query will read the entire time range available in the source table during each execution.

Alert Time Range

Typically, alert queries are executed once per interval. However, if one or more intervals are skipped due to errors or slow queries, the following execution will use a time range that includes the missed intervals. In this case, the query's interval parameters would still be set to the alert's configured period, but the time range parameters would reflect the longer time range.

Example alert queries​

Error rate per service (time-series)​

Alert when any service has an error rate above 5%, with at least 10 requests in the alert period to avoid noisy alerts on low-traffic services.

WITH error_rates AS (
  SELECT
    $__timeInterval(Timestamp) as ts,
    ServiceName,
    countIf (SpanKind = 'Server') as request_count,
    countIf (
      SpanKind = 'Server'
      and StatusCode = 'Error'
    ) as error_count,
    error_count / request_count * 100 AS error_percent
  FROM $__sourceTable
  WHERE $__timeFilter(Timestamp)
  GROUP BY ts, ServiceName
)
SELECT ts, ServiceName, error_percent
FROM error_rates
WHERE request_count > 10

Display type: Line or Stacked Bar Threshold: >= 5 (fires when error rate reaches 5%)

In this query, ServiceName is a non-numeric, non-timestamp column, so each service is tracked as a separate alert group. The alert fires independently per service.

Anomaly detection with lagging average (time-series)​

Alert on excess error counts that exceed a rolling average by more than two standard deviations. This catches spikes relative to recent baseline behavior rather than a fixed threshold.

WITH buckets AS (
  SELECT
    $__timeInterval(Timestamp) AS ts,
    count() AS bucket_count
  FROM $__sourceTable
  WHERE TimestampTime >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
        - toIntervalSecond($__interval_s * 30) -- Fetch 30 intervals back
    AND TimestampTime < fromUnixTimestamp64Milli({endDateMilliseconds:Int64})
    AND SeverityText = 'error'
  GROUP BY ts
  ORDER BY ts
  WITH FILL
    FROM toDateTime(fromUnixTimestamp64Milli({startDateMilliseconds:Int64}))
    TO toDateTime(fromUnixTimestamp64Milli({endDateMilliseconds:Int64}))
    STEP toIntervalSecond($__interval_s)
),

anomaly_detection AS (
  SELECT
    ts,
    bucket_count,
    avg(bucket_count) OVER (
      ORDER BY ts ROWS BETWEEN 30 PRECEDING AND 1 PRECEDING
    ) AS previous_30_avg,
    stddevPop(bucket_count) OVER (
      ORDER BY ts ROWS BETWEEN 30 PRECEDING AND 1 PRECEDING
    ) AS previous_30_stddev,
    greatest(
      bucket_count - (previous_30_avg + 2 * previous_30_stddev), 0
    ) AS excess_error_count
  FROM buckets
)

SELECT ts, excess_error_count
FROM anomaly_detection
WHERE ts >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
  AND ts < fromUnixTimestamp64Milli({endDateMilliseconds:Int64})

Display type: Line Threshold: > 0 (fires when excess errors above the rolling baseline are detected)

Note that the query fetches 30 intervals before the start of the date range to seed the rolling window calculations, then filters the final output to only the evaluation window.

Common alert scenarios​

Here are a few common alert scenarios you can use HyperDX for:

Errors: We recommend setting up alerts for the default All Error Events and HTTP Status >= 400 saved searches to be notified when excess errors occur.

Slow Operations: You can set up a search for slow operations (e.g., duration:>5000) and then alert when there are too many slow operations occurring.

User Events: You can also set up alerts for customer-facing teams to be notified when new users sign up or a critical user action is performed.