Configure Alert Checks

Configuring Checks in Dash0 is straightforward and allows for addition of notifications afterwards.

Set Up a Check Rule

To begin setting up a check rule, follow these steps:

1. Define the query: Build a query to count events, assess metrics, group by one or more dimensions, and in doubt go full PromQL on all collected telemetry.
2. Set alert conditions: Specify degraded and critical thresholds, select evaluation time frames, and configure additional enablement conditions.
3. Configure notifications and automations: Customize a notification summary and detailed description using variables. Decide on notification delivery methods for your teams (e.g., email, Slack, or webhook).

Build a Query

Use our query builder to define what you want to check for based on trace, logs, or metric data — or switch to raw PromQL to access all telemetry in a unified way and unlock the most advanced use cases. The query definition of the check rule will not only specify the metrics that you will get alerted on — but color your product experience and determine how often you will be notified by the system.

For example:

Rule will trigger once for the frontend service.

Rule will trigger for each operation of the frontend service separately (note the added operation name to the sum aggregation).

Create Meta Check Rules

Check rules can also query Dash0's own check metrics (dash0.check.*Copy, dash0.issues.*Copy, dash0.synthetic_check.*Copy), enabling you to create higher-level alerts based on the status of other checks. This is useful for grouping multiple related checks into a single alert, reducing alert fatigue by consolidating notifications.

Common use cases:

Aggregate check failures — alert when any check in a specific group fails:

1
sum by (team) {otel_metric_name = "dash0.check.status"} > $__threshold

Monitor synthetic check execution metrics — alert when the number of synthetic check runs in a location exceeds expected levels:

123
sum by (dash0_synthetic_check_location) (
  increase({otel_metric_name = "dash0.synthetic_check.runs", dash0_check_type = "synthetic.http"}[10m])
) > $__threshold

Or when the p90 latency exceeds the expected threshold:

123
histogram_quantile(0.9, sum by (dash0_synthetic_check_location)
  (rate({otel_metric_name = "dash0.synthetic_check.http.total.duration", dash0_check_type = "synthetic.http"}[5m]))
) > $__threshold

Technical Notes

• Label Renaming: When a meta check rule evaluates Dash0 check metrics, original labels like dash0_check_*Copy, dash0_resource_*Copy, and dash0_issue_*Copy are automatically renamed with an _originalCopy suffix (e.g., dash0_check_id_originalCopy) to prevent conflicts with the meta check rule's own labels.
• Meta Check Identification: Metrics generated by meta check rules are labeled with dash0_check_type=meta_check_ruleCopy.
• Loop Prevention: Meta check rules do not evaluate other meta check rule metric time series, preventing infinite evaluation loops.

Browse Query Templates

Dash0's templates use the popular "Awesome Prometheus alerts" to offer ready-to-use monitoring solutions crafted by the community and trusted by many. With these templates, you can:

• Skip the hassle of building monitors from the ground up.
• Achieve robust, end-to-end monitoring across all your critical integrations effortlessly.

While exploring the Prometheus alerts, we will indicate if the respective metrics are available in Dash0.

In case they are not collected yet, we point you to the respective integration so you can start gathering the necessary metrics for the respective technology.

Define Thresholds

Dash0 supports two severities: degraded and critical. The check will appear/resolve and increase or decrease the severity considering the respective specified grace period.

Set Enablement Conditions

Enablement conditions allow you to restrict when the check rule should be evaluated. As usual, you can use any existing telemetry for the conditions. For example, you can use enablement conditions to design check rules that only trigger when your system has relevant activity.

Choose an Evaluation Frequency

The evaluation frequency determines how often Dash0 runs the check query. Typically, this frequency is set to 1 minute, meaning that each minute the check assesses the chosen time series and compares the aggregated result to the defined thresholds.

Supported frequencies: 1 minute, 5 minutes, 10 minutes.

Configure Grace Periods

Two grace periods can be configured:

• Trigger grace period: Determines how long a query must continuously exceed the defined threshold before triggering the check.

• Keep-firing grace period: Sets how long a query remains in a degraded or critical state after it no longer meets the threshold condition.

Supported durations: 0s, 10s, 30s, 1 minute, 2 minutes, 5 minutes, 10 minutes.

How Raw PromQL Expressions Are Parsed

When you enter a raw PromQL expression, Dash0 analyzes it to extract a main expression with a threshold and optional enablement conditions. Understanding this process helps you write expressions that behave the way you intend.

Step 1: Extract Enablement Conditions

Dash0 looks for top-level andCopy operators in the expression. When found, the right-hand side of each andCopy becomes an enablement condition, and the left-hand side becomes the candidate for the main expression. This process repeats from right to left until no more top-level andCopy operators remain. This aligns with regular Prometheus expression handling, where the 'left' side of the expression generates the time-series and their values, and the 'right' side can only invalidate these results (remove from the final result). By separating though, Dash0 makes it possible to generate metrics to identify if a alert was not firing due to the threshold, or due to enablement conditions not passing.

Vector matching clauses like ON (label1, label2)Copy are preserved and used to correlate the enablement condition with the main expression. IGNORINGCopy clauses are recognized but do not restrict label matching.

Step 2: Extract the Threshold

From the remaining main expression, Dash0 looks for a comparison operator (==Copy, !=Copy, >Copy, >=Copy, <Copy, <=Copy) where the right-hand side is a scalar value or the $__thresholdCopy placeholder. If found, this becomes the configurable threshold in the check rule UI. If the expression is more complex (e.g., uses non-comparison binary operators), it is treated as an opaque expression without a separately configurable threshold.

Example

Consider this expression that checks whether a MySQL replica is down while it is expected to be replicating:

123
mysql_up == 0
and on(instance)
mysql_slave_status_master_server_id > 0

Dash0 processes this as follows:

1. Enablement condition extracted: The and on(instance)Copy splits the expression. Everything to the right becomes the enablement condition, including the > 0Copy comparison:

   • Enablement condition: mysql_slave_status_master_server_id > 0Copy, matched on label instanceCopy
   • Main expression candidate: mysql_up == 0Copy

2. Threshold extracted: From the main expression, == 0Copy is identified as the threshold.

The result is a check that only fires on instances that are configured as replicas (mysql_slave_status_master_server_id > 0Copy) and where the MySQL process is down (mysql_up == 0Copy).

Grouping Matters

If you intended > 0Copy to be the configurable threshold rather than part of the enablement condition, you need to restructure the expression so that the comparison applies to the overall result. Wrapping the andCopy portion in parentheses changes what Dash0 treats as the top-level operator:

123
(mysql_up == 0
and on(instance)
mysql_slave_status_master_server_id) > $__threshold

Here the outer > $__thresholdCopy becomes the threshold for the entire combined expression, and the andCopy inside the parentheses is no longer at the top level, so no enablement condition is extracted. The full expression, including the andCopy, is treated as the main expression, and > $__thresholdCopy is the configurable threshold.

Similarly, for a expression such as:

1
({otel_metric_name=“dash0.spans”} > 0) > 42

Even if there would be no explicit grouping, the right-most > 42Copy is used as (fixed) threshold. The > 0Copy will simply be part of the 'main' expression, meaning only time-series will be returned with a value higher than zero. For all resulting time-series with a value higher than zero, they will be evaluated against the threshold and corresponding metrics such as dash0.check.statusCopy will get created.