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:

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.
Set alert conditions: Specify degraded and critical thresholds, select evaluation time frames, and configure additional enablement conditions.
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).

Use our query builder to easily 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.

Info

The check rule will trigger on each distinct time series.

For example:

Rule will trigger once for the frontend service:

Request rate service builder

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

Query service request count by operation

Create Meta Check Rules

Check rules can also query Dash0's own check metrics (dash0.check.*, dash0.issues.*, dash0.synthetic_check.*), 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:

promql

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:

promql

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:

promql

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_*, dash0_resource_*, and dash0_issue_* are automatically renamed with an _original suffix (e.g., dash0_check_id_original) 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_rule.
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.

Template available

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 easily.

Template not available

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.

Check rule thresholds

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.