> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Demo days - 2026-07-31
> ClickStack demo days for 2026-07-31
Exponential histogram metrics
*Demo by [@pulpdrew](https://github.com/pulpdrew)*
Initial query support has landed for OpenTelemetry exponential histogram metrics. You could already register one of these metrics on a source, but there was no way to query it. Counts and quantiles now work through the query builder.
Exponential histograms are similar to explicit bucket histograms, but their bucket bounds are calculated from powers of two instead of being stored for each bucket. The scale controls which power of two is used. A higher scale produces smaller buckets, while the offset shifts the bounds towards higher or lower multiples. Each bucket count records how many observations fall within that range.
Max, min, sum and avg remain unsupported, matching the existing explicit histogram implementation. Those fields are optional in the OpenTelemetry data model, so we don't rely on them being present.
As the demo shows, the generated SQL is long and not particularly pretty. It performs acceptably and doesn't run out of memory, but this is initial functional support only. Performance is the next piece of work, and an updated schema is already in progress that should make these queries considerably quicker.
For now, only the time series display type renders correctly. This is consistent with the existing histogram metric type.
**Related PRs:** [#2687](https://github.com/hyperdxio/hyperdx/pull/2687) feat: Show exponential histogram metrics in the metric name drop-down, [#2697](https://github.com/hyperdxio/hyperdx/pull/2697) feat: Implement quantile+sum for exponential histogram metrics, [#2705](https://github.com/hyperdxio/hyperdx/pull/2705) feat: Support exponential histograms in MCP, [#2707](https://github.com/hyperdxio/hyperdx/pull/2707) fix: Support grouping histogram quantile aggregations over non-Attribute columns
Validation for raw SQL charts
*Demo by [@pulpdrew](https://github.com/pulpdrew)*
Raw SQL charts now warn when expected macros are missing. This came from a support case where someone building a large number of raw SQL charts kept getting confusing results.
Dashboard queries should include the filters and source table macros. Time series charts should also include the time range and interval macros. Previously, these checks only ran after an alert had been attached to the tile. They now run for every raw SQL chart, so removing a macro shows a warning in the editor instead of producing a puzzling chart later.
The validation also accounts for each macro's dependencies. The source table and filters macros require a selected source, even though raw SQL charts don't otherwise need one. Using either macro without selecting a source therefore produces an error rather than a warning.
It is a small change, but it should make raw SQL problems easier to find without going through support.
**Related PRs:** [#2742](https://github.com/hyperdxio/hyperdx/pull/2742) feat: Warn on missing params/macros in SQL Editor
Link to sources by name, not ID
*Demo by [@pulpdrew](https://github.com/pulpdrew)*
The LogHouse team requested a more stable way to link to sources. They run the logging environment for ClickHouse Cloud and provision sources programmatically using infrastructure as code. Source IDs change when a source is recreated and differ across development, staging and production, making any link based on an ID fragile. Because they link into ClickStack from alerting systems and Grafana, maintaining a separate set of source IDs for each environment wasn't practical.
The `source` URL parameter now accepts a source name as well as an ID. Names are controlled when sources are provisioned, so the same link can work in every environment. Support was initially added to the search page. A follow-up PR extends it to every page with a source parameter, including the chart explorer, service map, sessions, services dashboard and Kubernetes dashboard.
Most of the follow-up discussion focused on discoverability. This is effectively a URL API, and people are unlikely to find it by accident. One option is to use names instead of IDs by default, although name collisions make that unsafe. Other suggestions included exposing links through a share button, having agents generate them through the MCP, and documenting the URL API properly. Relative time ranges would benefit from the same documentation.
Name-based references could also be extended to dashboards. An infrastructure-as-code workflow could then provision sources, import dashboards and connect everything automatically. Dashboard imports through the UI already match sources by name, so the remaining gap is mostly in programmatic workflows.
**Related PRs:** [#2746](https://github.com/hyperdxio/hyperdx/pull/2746) feat: Accept source names in addition to IDs in URL Params, [#2758](https://github.com/hyperdxio/hyperdx/pull/2758) feat: Support source name deeplinks on additional pages
Chart display settings redesign
*Demo by [@elizabetdev](https://github.com/elizabetdev)*
Work is in progress on where chart display settings should live. The original change moved them inline to the right of the tile editor instead of opening them in a separate drawer. Previously, the tile editor was a modal and Display Settings opened in a drawer above it. Pressing Escape once closed both, and a drawer on top of a modal never felt right.
The PR became more complicated once series settings also needed to stack on top, so we stepped back and started looking at the page more broadly. The work is still at the wireframe stage. The current design puts settings in a docked panel and applies changes automatically, letting you see the result in real time without pressing an Apply button.
The plan is to finish the redesign before bringing it back into the existing PR. What is there now is being treated as a prototype, particularly because the new design also changes parts of the dashboard page.
**Related PRs:** [#2721](https://github.com/hyperdxio/hyperdx/pull/2721) feat(dashboards): move tile editor to a drawer with docked settings panel
New explore page
*Demo by [@elizabetdev](https://github.com/elizabetdev)*
This is an early exploration of a unified Explore page that could eventually replace Search, Saved Searches and Chart Explorer with a single entry point.
The rollout is informed by what we learned from the trace viewer redesign. Instead of changing the experience for everyone at once, the new page would launch behind a feature flag for a small group of users. We would use that period to find and fix problems before rolling it out more widely. If the idea doesn't work, it stays an experiment and doesn't ship. That is a perfectly good outcome.
The page begins with a signal type. Choosing traces, logs or metrics changes the rest of the experience to match. Selecting logs, for example, gives you the list view, event patterns, time series and the other visualisations currently found in Chart Explorer.
An investigation should be able to continue without switching pages. You might start with a list, move to a number or grouped table, add the result to a dashboard, then write a custom query if you need more control.
Several smaller ideas are included, most of them prompted by user feedback. The query editor would work more like the SQL editor, removing the current differences in autocomplete behavior. Errors and warnings would appear as you edit instead of waiting until the query runs.
Columns would get a dedicated picker. At least one user didn't realise that changing the `SELECT` clause controlled which columns appeared in the table. With the picker, clicking a field updates the SQL and lets you sort by that field. The `SELECT` clause remains available for advanced users.
Saved views would also live on the page, so you could explore without saving and then save the current view in place. Generated SQL would be shown inline.
A fair amount is still missing, including some of the visualisations available in Chart Explorer today. The design will continue to change as those pieces are added.
**Related PRs:** none yet, this is an exploration rather than a shipped feature
Dashboard filter linking
*Demo by [@teeohhem](https://github.com/teeohhem)*
Dashboard filter linking has merged. We first demoed it in draft several months ago, then paused while working through the performance implications. Linking changes the shape of dashboard queries and doesn't always make optimal use of materialized views, so it will ship as an opt-in toggle rather than the default.
When linking is enabled, choosing a value in one filter narrows the values available in the others. Selecting a service leaves only the severity values found for that service. Selecting a trace ID leaves only the related parent trace IDs. This prevents users from choosing combinations that return no data.
A follow-up PR makes the linking source-aware. Filters are grouped by source, with chain icons between neighbouring filters that can narrow each other. On a dashboard with two log filters and two trace filters, it should be clear which filters interact.
The original use case was the Kubernetes dashboard. Selecting a pod should leave only the deployments and nodes that contain that pod. Narrowed values are fetched lazily when a dropdown opens, limiting the cost of the additional lookups.
The discussion left two open questions. The setting is currently stored per user in browser storage. The expectation from the call was that people will eventually want it saved at the dashboard level. If so, the user-level preference may be better kept temporary rather than competing with dashboard-level behavior later.
The other question is how dependent filters behave while their values are loading. Selecting a value currently shows a loading state inside the dependent dropdown instead of blocking it, although the behavior with a second dependent filter still needs to be verified. The preference was to keep filters usable while narrowing is in progress and show that the list hasn't finished updating. Someone who already knows the value they want shouldn't have to wait for metadata.
**Related PRs:** [#2423](https://github.com/hyperdxio/hyperdx/pull/2423) feat(dashboards): cascading (faceted) filter values, [#2760](https://github.com/hyperdxio/hyperdx/pull/2760) feat(dashboards): persist filter link toggle and clarify within-source linking
Remember the last side panel tab
*Demo by [@MikeShi42](https://github.com/MikeShi42)*
The smallest PR of the week is also a good example of an irritation worth fixing.
The row side panel always opened on the Overview tab, which is designed around OpenTelemetry log fields. For logs that aren't OTel-shaped, the tab shows very little useful information. You end up switching to Column Values every time you open a row.
The panel now remembers the last tab you used and opens it again next time. There is nothing to configure. Non-OTel users who switch to Column Values will stay there, while everyone using Overview keeps the existing behavior.
**Related PRs:** [#2752](https://github.com/hyperdxio/hyperdx/pull/2752) feat(app): remember last-used side panel tab across opens