Dash0 review

Dash0 is an observability platform, not an instrumentation library. Its product combines a web interface and query surfaces with SignalStore, an OpenTelemetry-native data platform that Dash0 says stores signals in your cloud. The listed signal types are logs, metrics, traces, profiles, events and RUM data. Dash0 also presents AI software development insights and production automation as parts of the same platform.

In a stack, applications and agents send telemetry through OpenTelemetry-compatible tools; engineers and AI agents then query and explore that data through PromQL, SQL, a CLI, an API or an MCP server. Dash0's stated goal is to connect production signals to code and support live insights, root-cause analysis, automatic fixes and auto-tuning. SignalControl lets teams select telemetry to keep, with storage costs applying to what they retain. The architecture is designed to reduce dependence on proprietary telemetry formats, but teams should validate how their existing collectors, dashboards and alerting fit before switching.

Dash0 lists an API, CLI and MCP server as ways for people and AI agents to access the same signal store. It also supports PromQL and SQL query access, and describes compatibility with OTel-compatible tools, agents and SDKs. Configuration as Code is intended to put dashboards, rules and other configurations in editors and existing release pipelines.

The homepage does not name specific Dash0 SDKs, programming languages, API protocols or CLI commands. Confirm SDK support, authentication, API versioning, pagination and query limits in Dash0's documentation before you build a production integration. The same applies to whether your current OpenTelemetry collector, instrumentation libraries and deployment setup are supported as configured.

Dash0's product pages include documentation, guides, integrations and a changelog, but teams should check those references for the exact setup path for their stack. The key integration proposition is using OpenTelemetry and open query interfaces rather than adopting a proprietary instrumentation format.

Dash0 lists one usage-based plan, Telemetry, and no permanent free plan. A 14-day unlimited free trial is available without a credit card. The pricing page describes monthly usage pricing and lists no annual billing option.

For spans, logs and web events, the listed rate is $0.060 per million ingested and $0.540 per million stored, with 30-day retention. Metric data points cost $0.020 per million ingested and $0.180 per million stored, with 13-month retention. Synthetic API checks are $0.20 per thousand stored, with 13-month retention; session replays are $2.00 per thousand stored, with 30-day retention. These separate ingestion and storage meters mean a production estimate needs both signal volume and retention. Agent0 Credits are a metered monthly add-on at $0.60 per credit. The pricing page does not list a starting monthly price, seat charge or annual discount. Model each signal type separately and confirm how your expected usage will be measured before committing.

Dash0 describes the platform as OpenTelemetry-native and says it uses open interfaces rather than a proprietary telemetry format. It also says customers can export data anytime. Those claims support portability at the signal level, but do not establish that Dash0's application is open source or that its full service can be self-hosted.

The vendor does not publish a Dash0 software licence or a self-hosted-server option on the vendor's site. SignalStore is described as storing data in your cloud; that is distinct from running the Dash0 service yourself. Ask Dash0 what components run in your cloud, what data must pass through its service, and what export formats and query definitions are available.

Using OpenTelemetry can make a backend migration easier, but dashboards, alerts, automation and AI features may still need to be recreated. A commenter on Reddit notes that UIs and alerts can be a source of lock-in across observability tools.

Dash0's pricing lists retention periods by signal type, but the vendor does not publish numeric rate limits on the vendor's site. Before production use, ask about ingest and query quotas, service availability commitments, data residency, access controls, encryption, incident response and compliance certifications. The homepage links to a security section, but teams should review its current details rather than assume a specific control or certification.

Cost control also needs attention: ingestion and storage are separate meters for spans, logs, web events and metrics, while checks and replays have their own stored-data rates. Set a forecast using representative signal volume and retention, then confirm how SignalControl changes billing.

A Reddit user who switched from Datadog reports paying half as much, while missing some minor features. Another commenter says standardizing OpenTelemetry across .NET services can be confusing. Treat both as individual reports, not guarantees; validate your own instrumentation, workflows and feature requirements.