Dash0 Raises $110M Series B at $1B Valuation

Last updated: May 29, 2026

Configure Meta Check Rules

Meta check rules monitor the health of other check rules and synthetic checks, enabling higher-level alerting patterns. Instead of alerting on application metrics directly, meta checks alert when your monitoring system itself is experiencing issues.

Use Cases for Meta Check Rules

Meta check rules provide higher-level monitoring by tracking the health of your alerting system itself. Meta check rules are useful for:

  • Monitor check rule health: Alert when too many check rules are failing across a team or environment
  • Track synthetic check performance: Monitor the latency or success rate of synthetic checks
  • Aggregate failure patterns: Detect systemic issues when multiple related checks fail simultaneously
  • Monitor alerting coverage: Ensure critical services have active check rules

Create a Meta Check Rule

Creating a meta check rule follows the same process as creating a regular check rule, but uses special Dash0 metrics that track check rule execution and results. These examples demonstrate common meta check patterns.

Monitor Aggregated Check Failures

Alert when a team has too many failing check rules:

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

This query groups check failures by the team label and alerts when any team exceeds the threshold.

How it works:

  • Each failing check rule emits a dash0.check.status metric
  • The query sums these by team label
  • When a team has more than the threshold number of failures, the meta check fires

Monitor Synthetic Check Latency

Alert when synthetic checks are experiencing high latency:

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

This query calculates the P90 latency of synthetic HTTP checks grouped by location.

How it works:

  • Synthetic checks emit duration metrics
  • The query calculates P90 latency per location
  • Alerts when any location exceeds the latency threshold

Monitor Check Rule Coverage

Ensure all critical services have active check rules:

promql
1
count by (service_name) {otel_metric_name = "dash0.check.status", service_name != ""}

Combine this with an enablement condition that only fires when the count is zero for a critical service.

Meta Check Technical Details

When creating meta check rules, be aware of these technical behaviors that prevent conflicts and ensure proper operation.

Label Renaming

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 when the meta check itself generates metrics.

Example:

  • Original check rule has label: dash0_check_id=abc123
  • In meta check metrics, this becomes: dash0_check_id_original=abc123
  • The meta check's own ID uses: dash0_check_id=xyz789

Meta Check Identification

Metrics generated by meta check rules are labeled with dash0_check_type=meta_check_rule to distinguish them from regular check rules and synthetic checks.

This allows you to:

  • Filter for meta checks specifically in queries
  • Create dashboards showing only meta check status
  • Route meta check notifications differently

Loop Prevention

Meta check rules do not evaluate metrics from other meta check rules, preventing circular dependencies and infinite loops.

What this means:

  • A meta check cannot monitor other meta checks
  • The dash0.check.status metric only includes regular check rules and synthetic checks
  • You can safely create multiple meta checks without worrying about cross-monitoring

Available Meta Check Metrics

Use these specialized metrics in your meta check queries to monitor the health and performance of your alerting system. Dash0 provides these metrics for meta check rules:

  • dash0.check.status: Current status of check rules (0=OK, 1=Degraded, 2=Critical)
  • dash0.check.evaluation.duration: Time taken to evaluate a check rule
  • dash0.check.evaluation.errors: Count of evaluation errors
  • dash0.synthetic_check.http.total.duration: Synthetic HTTP check duration
  • dash0.synthetic_check.success: Synthetic check success/failure (1=success, 0=failure)

See the Dash0 metrics documentation for a complete list of available meta check metrics.

Best Practices

Follow these guidelines to create effective meta checks that provide valuable insights without adding noise or performance overhead.

Start with High-Level Aggregations

Begin with broad meta checks that aggregate across teams or environments before creating detailed per-service meta checks.

Good starting point:

promql
1
sum {otel_metric_name = "dash0.check.status", severity = "critical"} > 10

Use Enablement Conditions

Prevent false alerts during maintenance windows or low-traffic periods:

promql
12345
# Main query: count failing checks
sum {otel_metric_name = "dash0.check.status"} > $__threshold


# Enablement condition: only alert during business hours
hour() >= 9 AND hour() < 17

Set Appropriate Grace Periods

Meta checks should have longer grace periods than regular checks to avoid alert fatigue from transient issues:

  • Regular checks: 1-2× grace period
  • Meta checks: 3-5× grace period

Group by Relevant Dimensions

Choose grouping labels that align with your team structure:

promql
12345678
# Group by team for team-specific alerts
sum by (team) {otel_metric_name = "dash0.check.status"}


# Group by environment for environment-specific alerts
sum by (deployment_environment_name) {otel_metric_name = "dash0.check.status"}


# Group by service for service-specific coverage checks
count by (service_name) {otel_metric_name = "dash0.check.status"}

Further Reading