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

Last updated: July 5, 2026

Set Guardrails

Control Agent0's behavior and ensure safe execution with guardrails configuration.

Set guardrails to control what Agent0 can do when your automation runs. Guardrails ensure automations are safe, predictable, and only perform the actions you intend.

Guardrails settings showing network access, tools, timeout, and concurrency options

Network Access

Controls whether Agent0 can make outbound network requests to external systems.

Options

  • 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 operations, webhooks, curl).
  • Full Network: Agent0 can make any outbound request, including sandbox-native operations like git/gh CLI and webhooks.
Note

A third option, "Trusted Only," exists in the UI but is feature-flagged and not generally available. It allows access to trusted integrations only. Most users should choose between "No Network" and "Full Network."

Tip

Start with No Network and only enable Full Network when needed. This prevents accidental external actions during testing.

Timeout

Maximum time Agent0 can run before the automation stops. Default is 10 minutes.

Set higher timeouts for automations that:

  • Query large time ranges
  • Analyze many services
  • Perform complex calculations

Set lower timeouts to catch runaway executions quickly during testing.

Examples:

  • Simple Slack response: 1-2 minutes
  • Daily health report: 5-10 minutes
  • Deep incident analysis: 15-20 minutes

Allowed Tools

Controls which Dash0 tools and integrations Agent0 can use.

Leave this section empty to use smart defaults:

  • Agent0 can always query Dash0 data (metrics, logs, traces, services, checks)
  • Agent0 can post to Slack only when triggered by a Slack event
  • Agent0 can comment on GitHub only when triggered by a GitHub event
  • Agent0 can post to Linear only when triggered by a Linear event

This prevents scheduled automations from accidentally posting to Slack, or Slack-triggered automations from modifying GitHub.

When to Customize

Override allowed tools when you need:

Scheduled automations that post to Slack:

  • Allow slack:slackSendMessage
  • Agent0 can now post daily reports or scheduled alerts

Read-only automations:

  • Allow only dash0:*
  • Agent0 can query data but not use integration tools

Specific tool restrictions:

  • Allow slack:slackSendMessage but not slack:slackAddReaction
  • Fine-tune which actions are permitted

Tool Namespaces

  • dash0:* — All Dash0 data queries (always safe to allow)
  • slack:* — All Slack actions (posting, updating, reading channels)
  • github:* — All GitHub actions (requires GitHub integration)
  • linear:* — All Linear actions (requires Linear integration)

Specific Tools

Common tools to allow individually:

  • slack:slackSendMessage — Post messages to Slack
  • slack:slackAddReaction — Add emoji reactions to messages
  • github:githubListRepos — List accessible GitHub repositories

Denying Specific Tools

If you allow a namespace but want to block specific tools within it, use the Manage Tools dialog in the UI:

  1. Click Manage Tools in the Allowed Tools section
  2. Find the tool you want to block
  3. Set its status to Denied

Example use case: Allow slack:* (all Slack tools) but deny slack:slackAddReaction (allow posting messages but prevent adding reactions).

This gives you fine-grained control: allow broad access while blocking specific risky operations.

Required Tool Calls

Tools that Agent0 must call for the automation to succeed.

Why Use This

Agent0 sometimes writes a summary and exits without taking action. For example:

  • Automation should post to Slack, but Agent0 only analyzes data
  • Automation should query metrics, but Agent0 responds from memory
  • Automation should post findings, but Agent0 just writes a report

Required tool calls ensure critical actions happen.

How It Works

If Agent0 finishes without calling a required tool:

  1. Agent0 gets one retry with an explicit reminder to call the missing tool
  2. If still missing, the run is marked as guardrail_failure
  3. You can see which tools were called in the run history

Example Use Cases

Slack alert automation:

  • Require slackSendMessage
  • Ensures findings are always posted, not just analyzed

Metric analysis:

  • Require getMetricQuery
  • Ensures Agent0 queries fresh data instead of guessing

Data-driven investigations:

  • Require both getMetricQuery and getLogRecords
  • Ensures Agent0 checks multiple data sources, not just one
Note

Use bare tool names (e.g., slackSendMessage), not namespaced names (e.g., slack:slackSendMessage).

Concurrency

Controls what happens when multiple events trigger the automation simultaneously.

Policies

None (Default):

  • Runs up to 50 automations in parallel, then queues additional triggers
  • Best for: Most automations unless you need specific control

Parallel:

  • Run multiple automations concurrently up to a maximum parallel count (default 50, not user-configurable in UI)
  • Best for: Read-only analysis with controlled parallelism
  • Example: Analyzing multiple failed checks concurrently

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: Posting sequential reports, updating shared resources
  • Note: Queue holds up to 100 triggers; extras are dropped
  • To run truly one-at-a-time, the max parallel count would need to be 1 (not exposed in UI)

Skip:

  • Drops new triggers when the number of running instances reaches the maximum parallel count (default 50)
  • Best for: When only the first event matters

Supersede:

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

When to Change

Most automations work fine with None (the default). Consider changing if:

  • Automation posts sequential updates → Queue
  • Automation takes long and new data makes old runs obsolete → Supersede
  • Automation should only run once at a time → Skip

Debounce

Delays automation execution until events stop arriving.

How It Works

Each matching event resets a timer. The automation only runs after the timer expires with no new events.

Example: Set to 10 seconds

  • Message arrives → timer starts
  • Another message arrives 5 seconds later → timer resets
  • No messages for 10 seconds → automation runs with latest message

When to Use

Useful when events arrive in bursts:

  • Multiple Slack messages about the same issue
  • Several commits pushed to a PR in quick succession
  • Rapid check failures during an incident

Debounce ensures Agent0 responds once after activity settles, not after every single event.

Pitfall

If events arrive more frequently than the debounce window, the automation never runs (timer keeps resetting).

Tip

When in doubt, leave debounce empty and use Concurrency settings instead. Concurrency is more predictable and won't silently prevent execution.

Tool Parameter Overrides

Force specific values for tool parameters, overriding what Agent0 chooses.

When to Use

Lock down Slack channels:

  • Always post to #incidents regardless of what Agent0 decides
  • Prevents posting to wrong channels

Enforce time ranges:

  • Always query the last 1 hour
  • Prevents Agent0 from using different timeframes

Pin dataset:

  • Ensure queries use the automation's dataset
  • Prevents accessing wrong data

Configuration

In the Tool Parameter Overrides section:

  1. Select the tool to override (e.g., slack.slackSendMessage)
  2. Add parameter overrides (e.g., channelId: C12345678)
  3. Values can include variables: {{slack.channel.id}}

Example Use Cases

Force Slack responses to triggering channel:

  • Tool: slack.slackSendMessage
  • Override: channelId = {{slack.channel.id}}
  • Result: Agent0 always responds in the same channel where the trigger fired

Pin metric query timeframe:

  • Tool: dash0.getMetricQuery
  • Override: timeframe.from = now-1h
  • Result: Agent0 always queries the last hour

Common Issues

For detailed troubleshooting, see:

Best Practices

  • Start restrictive: Begin with No Network, minimal Allowed Tools, and test thoroughly before enabling full access
  • Use defaults when possible: Leave Allowed Tools empty to use smart defaults based on trigger type
  • Require critical tools: If posting to Slack is the automation's main purpose, require slackSendMessage
  • Test with manual runs: Click Run Now to verify guardrails work as expected before enabling the automation
  • Prefer Concurrency over Debounce: Concurrency policies are more predictable and won't accidentally prevent execution

Further Reading