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

Last updated: July 5, 2026

Key Concepts

Core concepts and terminology for understanding Dash0 Automations.

Understanding automations requires familiarity with a few core concepts that govern how they're defined, triggered, and executed.

Automation Definition

An automation consists of four main components:

  • General settings: Name, description, and whether it's enabled
  • Triggers: One or more event types that fire the automation
  • Prompt: The instruction Agent0 receives when the automation runs
  • Guardrails: Constraints that control what Agent0 can do

When you create an automation, all these components work together to define its behavior.

Triggers

Triggers define when an automation runs. Each trigger watches for specific events:

  • Slack messages containing certain keywords
  • Failed checks in Dash0
  • GitHub pull requests being opened or updated
  • Scheduled times based on cron expressions
  • Linear comments on issues
  • Webhook requests sent to the automation's unique URL

Multiple triggers can be defined for one automation. When any trigger matches an incoming event, the automation executes.

Each trigger type exposes specific variables to your prompt. For example, Slack triggers provide {{slack.channel.name}} and {{slack.message.text}}, while check triggers provide {{check.name}} and {{label.service}}.

Variables

Variables are placeholders in your prompt that get replaced with real values when the automation runs.

Built-in variables work in every automation:

  • {{now}} — Current timestamp
  • {{today}} — Current date
  • {{dash0.dataset}} — Your Dash0 dataset

Trigger variables come from the event that fired:

  • {{slack.message.text}} — Message content (Slack triggers)
  • {{check.name}} — Failed check name (check triggers)
  • {{github.repository}} — Repository name (GitHub triggers)

Constants are custom values you define:

  • {{environment}} — Could be set to "production"
  • {{alert_channel}} — Could be set to "incidents"
  • {{team}} — Could be set to "platform-team"
Tip

Built-in variables like {{dash0.dataset}} cannot be overridden by trigger data or constants. This prevents external events from spoofing internal values.

Guardrails

Guardrails control what Agent0 can do during execution:

Network access:

  • No Network: Agent0 can query Dash0 data and use integration tools (Slack, Linear, GitHub API). The sandbox cannot make direct network requests (git/gh CLI, webhooks).
  • Full Network: Agent0 can make any outbound request, including sandbox-native operations like git/gh CLI and webhooks

Timeout:

  • Maximum time Agent0 can run before stopping (default: 10 minutes)

Allowed tools:

  • Which Dash0 features and integrations Agent0 can use
  • By default, Agent0 can read data but only write to systems that match the trigger source

Required tool calls:

  • Tools that must be called for the run to succeed
  • Ensures critical actions (like posting to Slack) actually happen

Concurrency:

  • How simultaneous triggers are handled (parallel, queue, skip, or supersede)

Debounce:

  • Delay that waits for events to stop arriving before running

Tools and Integrations

Tools are the actions Agent0 can take:

Dash0 tools query your observability data:

  • Metrics, traces, logs, services, and checks
  • Always available, no integration needed

Slack tools interact with your workspace:

  • Post messages, read channels, respond in threads
  • Requires Slack integration

GitHub tools read repositories:

  • List repositories
  • Requires GitHub integration (for PR comments use gh CLI via bash, which needs Full Network)

Linear tools read issues:

  • Search issues, get details, list teams and projects
  • Requires Linear integration (read-only)

By default, Agent0 can always query data but can only post to external systems when triggered by those systems. For example, Slack triggers can post to Slack, but scheduled triggers cannot (unless you explicitly allow it in guardrails).

Concurrency Policies

When multiple events trigger an automation at the same time, the concurrency policy determines what happens:

None (Default):

  • Runs up to 50 automations in parallel, then queues additional triggers
  • Best for most automations

Parallel:

  • Run multiple instances at once up to a maximum you configure
  • Best for read-only analysis with controlled parallelism

Queue:

  • Run up to the maximum parallel count concurrently (default 50), queue additional triggers beyond that
  • New triggers wait in the queue when max parallel count is reached
  • Best for operations that shouldn't overlap (truly one-at-a-time would require maxParallel=1, not exposed in UI)

Skip:

  • Only one run at a time
  • Ignore new triggers while running
  • Best when only the first event matters

Supersede:

  • New triggers cancel in-progress runs
  • Always use the latest data
  • Best when fresh context is more valuable than completing old runs

Runs

Each time an automation executes, it creates a run record showing:

  • Status: Success, error, or guardrail failure
  • Summary: Agent0's description of what it did
  • Tool calls: Every action Agent0 took with arguments and results
  • Duration: How long the run took
  • Trigger: Which event fired the automation

Run history is available in the automation's Runs tab. You can filter by status, review what Agent0 did, and provide feedback to improve future runs.

Debounce

Debounce is a delay that prevents rapid-fire executions when events arrive in bursts.

How it works:

  1. First matching event starts a timer
  2. Each new matching event resets the timer
  3. Automation runs only after the timer expires with no new events

Example: With a 10-second debounce, if messages arrive every 5 seconds, the automation only runs 10 seconds after the last message.

Note

If events arrive more frequently than the debounce window, the automation may never run because the timer keeps resetting. Use debounce carefully or prefer concurrency policies instead.

Templates

Templates are pre-built automations for common scenarios:

  • Incident triage when checks fail
  • PR review assistance for GitHub
  • Scheduled service health reports
  • Slack-driven queries and investigations

Templates include working trigger configurations, well-crafted prompts, and appropriate guardrails. Start with a template and customize it for your needs.

Datasets

Automations run within a specific Dash0 dataset, which determines what observability data Agent0 can access. The dataset is set when you create the automation and cannot be changed later.

All queries for metrics, logs, traces, and services use the automation's dataset. This ensures automations only access data within their intended scope.

Further Reading