Demo days - 2026-06-26
Anomaly detection for alerting continues with bar charts
Demo by @fleon
Still very much an experiment. The normal distribution bands used to highlight anomalies work well on line charts, but they're much harder to represent on bar charts. Himanshu experimented with error bands and even hollow bar charts to make the bands more visible, but the results still feel cluttered. Overlaying a band as a line on top of a solid bar has the same issue, as the bar dominates the visual and makes the band difficult to distinguish.
For now, we'll likely steer users toward the line chart when they want to inspect anomaly bands and revisit the bar chart design later. Himanshu is looking for feedback on the best approach before this ships.
Local Claude investigations now produce shareable notebooks
Demo by @pulpdrew
One of the more interesting demos, and one that still feels very much like an experiment, was a prototype for turning local Claude investigations into shareable notebooks.
The workflow starts with Claude investigating an alert using ClickStack MCP tools, either as a local session or one kicked off remotely by something like a webhook. When the investigation finishes, Claude produces a summary together with a link to a notebook containing the full investigation, with the option to make it public.
That notebook becomes much more than a transcript. Every MCP call is captured as its own tile and grouped by session ID. Claude's summary cites those tiles directly, so every claim can be traced back to the exact query that produced it. Those same citations also appear in the live Claude session because every MCP call returns a link to the tile it created.
The more interesting part comes next. The notebook isn't just something to read, it's something another developer can pick up. Drew copied a short snippet into a fresh Claude session, which immediately recreated the investigation with the notebook's summary, query history, and cited tiles already in context. The referenced queries are re-run using the developer's own RBAC permissions, ensuring the results are both current and scoped correctly. From there, Claude could continue the investigation, suggesting follow-up work like launching one subagent to assess customer impact and another to prepare a code fix. Their findings are then written back into the same notebook.
Making that work required surprisingly little plumbing. Each MCP request carries a session ID, and optionally a subagent ID, added by a small hook. Today that hook is documented in the team settings page, although the plan is to package it as a plugin. It's already working with Claude and OpenCode. Codex and Cursor work too, although without subagent IDs, so they can't yet display threaded subagent activity.
The discussion afterwards turned to the obvious questions. How do you stop notebooks from accumulating forever? How do you avoid capturing sensitive information? For now, notebooks are opt-in, private by default, and explicitly shareable. They're tagged so they're easy to find later, and the team is considering a TTL for notebooks that nobody ever returns to. On the security side, the hook only attaches session metadata to existing ClickStack MCP calls. It doesn't record the full agent conversation or output from other tools, deliberately sacrificing some context to reduce the risk of exposing sensitive information. It's still early, but it already feels like a natural way to make AI investigations reproducible, shareable, and easy to hand off.
External onclick actions for tables
Demo by @pulpdrew
Drew demoed a small but useful addition to dashboard tables: the ability to link rows directly to external tools.
Table rows already support drilling into Search or another dashboard. This introduces a third option, "External", which builds a URL using values from the selected row before opening it. In the demo, clicking a row from a product catalog inserted the product name into a Google search URL to illustrate the concept, but the same mechanism works just as well for linking into Grafana, internal runbooks, ticketing systems, or any other tool that accepts parameters in a URL.
It's a straightforward feature, but an important one. Instead of treating ClickStack as a destination, it becomes another part of the wider observability workflow, making it easy to jump from a dashboard directly into the tools needed to continue an investigation.
Related PRs: #2523 feat: support external links via dashboard table on-click behavior
OTel profiling
Demo by @SpencerTorres
Profiling is beginning to make its way into ClickStack, although it's clearly still taking shape. Spencer demoed an early prototype that ingests OpenTelemetry profiling samples, the same data used to generate flame graphs and consumed by tools like pprof. Using a Grafana dashboard backed by ClickHouse, he visualized a small program repeatedly sorting data, drilling into individual call stack blocks as new profiling samples streamed in.
The implementation is still fairly rough, and the query reflects that. Each row combines elements of logs and traces, storing long arrays of function names and addresses that represent a span or slice of a flame graph. Reconstructing the format Grafana expects requires joining and aggregating across those arrays, while the exporter has to unwind the raw profiling frames before writing them into ClickHouse. The schema still relies on bloom filters, with full text search now added as well, prompting a discussion about compatibility. Since ClickHouse Cloud already supports full text search, the team debated how much longer the open source path without it needs to be maintained.
The work is currently under review in an open PR. The plan is to land the core functionality in open source first before integrating it into ClickStack.
Autocomplete for OTel metric sources
Demo by @brandon-pereira
Brandon demoed a small quality-of-life improvement for metrics onboarding. When creating an OpenTelemetry Metrics source, the metric table fields now autocomplete by matching table names in the selected database instead of requiring each one to be selected manually. It also brings metrics into line with the onboarding experience that logs and traces already provide.
Related PRs: #2524 feat(app): auto-fill metric table dropdowns in Create Source form
Eval framework for dashboards
Demo by @brandon-pereira
AI-generated dashboards are improving, but judging progress by eye only gets you so far. Brandon is building an evaluation framework to measure whether dashboard generation is actually getting better, and just as importantly, where it still falls short.
The evaluation prompts the model to generate a dashboard that deliberately exercises as many features as possible, including collapsible sections, tabs, heatmaps, pie charts, raw SQL alongside source-backed tiles, service-level filters, and drill-down links between dashboards.
A grading pass then validates that everything rendered and behaved as expected. In the process, it's already uncovered genuine issues, including markdown tiles that consistently render too short. It also follows the drill-down links enabled by Drew's new onclick feature to verify that navigation into a second AI-generated dashboard works correctly. As new dashboard capabilities are added, they'll be folded into the evaluation so regressions are caught automatically instead of relying on manual testing. Brandon is hoping to open a PR with the framework soon.
Related PRs: #2571 feat(hdx-eval): add dashboard-build eval scenario (in progress)
Connecting to Prometheus
Demo by @knudtty
Aaron demoed an early bridge between ClickStack and Prometheus. A new "Prometheus compatible" option in a source's advanced settings tells ClickStack to treat the configured host as a Prometheus API endpoint, Thanos in the demo, instead of a ClickHouse instance. Once enabled, dashboard tiles can execute PromQL directly against that endpoint. Aaron demonstrated this with a chart grouping CPU usage across pods, with the query sent straight to Prometheus rather than translated through ClickHouse. The demo itself was fairly small, but it prompted a broader discussion about the user experience.
Longer term, the goal is native Prometheus support within ClickStack. This feature is intended as a practical first step, allowing teams that already depend on Prometheus to continue using it while adopting ClickStack, rather than forcing everything through ClickHouse from day one. In parallel, we continue to work on supporting PromQL natively within ClickHouse.
Related PRs: #2518 feat: add ability to connect to external prometheus datastore
