Recent changes and improvements to Dash0

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 "/"Copy 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.logCopy 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=acmeCopy and an auth refresh triggered, they'd hit “/”Copy 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 "/"Copy 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=SRECopy to a dedicated Slack channel, or direct priority=p1Copy 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_statusCopy attribute.

Use dash0.failed_check.max_status=criticalCopy 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_statusCopy 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.

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 filterCopy.

There is more about Kubernetes events to come. We will add support for retrieving out-of-the-box Kubernetes events via the Dash0 Operator. 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.nameCopy attribute to allow filtering on the Kubernetes events eventNameCopy 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=trueCopy and having at least one namespace with a Dash0MonitoringCopy resource with prometheusScrapingCopy 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=trueCopy, 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.

We've introduced the ability to hide the main (top-most) chart in various explorers. Hiding these charts gives you more screen real estate to display more entries (e.g., more logs in the logs explorer).