Recent changes and improvements to Dash0

When configuring charts that support the calculation field, you can hover over any calculation type in the dropdown to see a visual example of how it processes your data points within the query window.

Each visualization clearly illustrates the behavior of the calculation, including how it treats numeric values, Not-a-Number (NaN) entries, and edge cases. Whether you're deciding between "First value" and "First non-null value", or wondering how "Instant" differs from "Last", these guides will help you pick which one to use.

You can access these examples in Dash0 by hovering over the info icon next to the Calculation dropdown.

The images are static, it does not adjust to the reality of the data. But let us know if you find this kind of visual hints useful!.

\

You can now send telemetry data through Amazon's private network backbone without exposing traffic to the public internet.

Key benefits:

• Enhanced security with private connectivity

• Reduced network egress costs by keeping traffic within AWS

• Compliance with strict data security requirements

• Support for isolated VPC workloads

Available regions: eu-west-1 (Ireland), us-west-2 (Oregon)

For more information see https://www.dash0.com/hub/integrations/int_aws_privatelink/overview

Starting with version 0.92.1 of the Dash0 operator, Kubernetes events are now automatically collected in monitored namespaces.

The collected events will be presented in our brand new Kubernetes event view in Dash0.

You can also filter for Kubernetes events in the logging page by using otel.event.name=k8s.event filter, or filter for specific events via the otel.event.name attribute.

See how Kubernetes events are emitted, collected by the Dash0 operator, and displayed in the new Kubernetes Events view:

Some of our end users reported an annoying issue: while working deep in the product, they would occasionally be unexpectedly redirected back to the Home page. No error, no explanation. Just... redirected to Home.

This bug had been haunting us on and off for a while. Somewhere in the chain of authentication refreshes and session handling, the app would sometimes route through "/" before restoring context. Our middleware would then dutifully add the organization parameter and send users on their way, but it had no memory of where they actually came from. The result? A one-way ticket back to the Home page.

We tried the traditional debugging approach: reading through code, adding breakpoints, sprinkling console.log statements everywhere, trying to reproduce locally. But the issue was intermittent and maddeningly hard to catch in the act.

Then we turned to Dash0 – as we always do.

We added custom logging to the middleware to capture the full context of each redirect: referrer headers, org parameters, request paths, and timing information. Once those logs were flowing into Dash0, the picture became clear almost immediately.

We could see the exact redirect patterns happening in production and trace the journey of affected requests. The culprit revealed itself: when a user was at /dashboards?org=acme and an auth refresh triggered, they'd hit “/” briefly, and our middleware had no idea they weren't supposed to be there.

The fix was straightforward once we understood the problem. When the middleware sees a request to "/" without an org parameter, it now checks if there’s any reference to where the user navigated from. If the user just came from a valid page on the same domain with a matching org, we send them right back instead of stranding them on the homepage.

This is one of the perks of building observability tooling. Having the right visibility helps us constantly improve and learn (even from these annoying bugs).

\

Two Ways to Route Alerts

You now have two options for specifying which notification channels receive which alert:

• Bind Notification Channels from Check Rules or Synthetic Checks: Assign notification channels directly within each check rule or synthetic check. This keeps your alert configuration all in one place and gives you explicit control at the individual check level.

• Map Notification Channels to Label-Based Conditions: Define conditions on notification channels to receive alerts that match specific labels. For example, route all alerts labeled team=SRE to a dedicated Slack channel, or direct priority=p1 alerts to PagerDuty, without modifying individual checks.

Severity-Based Routing

You can now also route alert notifications based on the severity of failed checks using the trigger notifications always or only on Critical options found in the check rule and synthetic check pages, or by using the dash0.failed_check.max_status attribute.

Use dash0.failed_check.max_status=critical as a condition on notification channels to ensure only critical alerts trigger pages, while team channels receive all severity levels for visibility.

The dash0.failed_check.max_status attribute reflects the highest severity a failed check has reached during its lifecycle. Once a check escalates to critical, all subsequent notifications route to channels matching that severity, even if the check temporarily returns to a degraded state. This guarantees that teams who were paged about a failed check will also be notified when it’s resolved.

For more details, see our documentation on Notifications and Routing.

Update 2025/12/16: Update the text to reflect that the Dash0 Operator automatically collects Kubernetes events since version 0.92.1.

Currently, the newly-introduced support for Kubernetes events is made of two things:

1. Normalizing the format of the Kubernetes events from k8seventsreceiver so that they fit nicely with the k8s.* semantic conventions and Dash0’s resource centricity concept.

2. A built-in view in Logging for Kubernetes events:

Besides, you can filter in the Logging page for Kubernetes events with the otel.event.name=k8s.event filter.

There is more about Kubernetes events to come. The Dash0 Operator also retrieves Kubernetes events out of the box for monitored namespaces. And soon™ Kubernetes events and other types of events are going to start playing a very important role in the way you monitor services.

Besides, we also added the otel.event.name attribute to allow filtering on the Kubernetes events eventName value.

Starting with version 0.90.0, it's now possible to specify custom node affinities for each component of the Dash0 Operator via the Helm chart. This allows to configure on which nodes the manager pod, collectors, and the (optional) target-allocator will be scheduled.

For more information, refer to the operator's documentation and the Node Affinity section in the Kubernetes documentation.

Dash0 has had Dashboard versioning built-in since day one, but we have never exposed it in the UI. Until now, that is.

Every time you save a Dashboard, it creates a new version. The version history dropdown allows you to browse previous states of your dashboard, compare what changed, and restore any older version with a single click.

If you're managing dashboards with Infrastructure as Code, or a dashboard is read-only to you due to Access Control settings, you can still explore its version history to see how it evolved over time and create a new Dashboard from any version with the “Save as new” button.

Whether you're experimenting with new layouts, rolling back an accidental deletion, or just curious about how your dashboard evolved, version history is your safety net to iterate freely.

Starting with release 0.87.0, the Dash0 operator supports widely used Prometheus CRDs like ServiceMonitor, PodMonitor and ScrapeConfig.

The new feature can be enabled by deploying the operator with prometheusCrdSupportEnabled=true and having at least one namespace with a Dash0Monitoring resource with prometheusScraping enabled.

From that point on, the Dash0 collectors will scrape the metrics endpoints defined in the Prometheus CRDs and the new metrics will be available in Dash0.

For more information, refer to the operator's documentation.

Every dataset now supports three roles: Viewer, Editor, and Maintainer. Viewers can explore all data and build non-intrusive assets like dashboards and views. Editors extend that by creating new check rules and synthetic checks. Maintainers hold the keys to telemetry-impacting settings - from spam filters to semantic convention versioning.

The result is flexibility with clarity. You can give broad access to non-critical datasets without worrying about accidental changes in production. And because roles are transparent, it’s always clear who has which level of control.

This is a major step toward balancing collaboration with protection, ensuring that Dash0 grows safely alongside your organization.

Read more

Starting with release 0.86.0 of the Dash0 operator, it now has full support for Google GKE Autopilot. Dash0 is now a GKE Autopilot partner, and the Dash0 operator can run as a privileged workload in Autopilot clusters.

Enable the Dash0 operator's autopilot mode by deploying the operator into your GKE Autopilot cluster with operator.gke.autopilot.enabled=true, and benefit from out-of-the-box telemetry collection that just works.

For more information, refer to the operator's documentation.

You can now bind any dashboard variable to any kind of filter in your queries, supercharging your custom dashboards and bringing a new level of dynamic control to all your observability views.

This update removes the previous limitation of variable usage only within specific query languages. We've introduced a flexible binding mechanism that allows you to map any existing dashboard variable to filters across all supported data sources. Be it logs, metrics, or traces.