hyperdxio/hyperdx

What happened? With the "Relative Time" switch on, the picker greys out every preset above "Last 1 hour". That covers 3h, 6h, 12h, 1d, 2d, 7d, 14d and 30d. Nothing says why. So you can't pick an auto-updating 6-hour or 24-hour window from the UI. The limit is in the picker only. If you set a longer live range in the URL (for example isLive=true&liveInterval=21600000 for 6 hours), search live-tails that window without trouble. The switch label adds to the confusion. It says "Relative Time", and only its hover tooltip mentions Live Tail. It isn't clear that the switch turns on live tail, or why it hides most of the ranges. What I expected: Longer live ranges (at least 3h, 6h, 12h and 24h) can be picked from the picker, like they can from the URL. If a limit is intended (for example, to keep query load down), the disabled options say so in a tooltip. The switch label makes clear that it controls live tail. Steps to reproduce Open Search on any log source, for example the default otel_l

What happened? When a dashboard refreshes, most tiles keep showing the old result with no loading sign until the new data arrives. Only line and stacked-bar time charts pulse while they refetch. Number, table, bar and pie tiles look finished the whole time. You can't tell stale values from fresh ones, and with live refresh on you may act on numbers that are minutes old. Expected: every tile shows that it is refreshing (for example the same effect-pulse the time charts use) while it keeps the previous result on screen. Steps to reproduce Create a dashboard on the default otel_logs source with four tiles: a line time chart, a Number tile (for example count()), a Table tile grouped by ServiceName, and a Pie or Bar tile grouped by SeverityText. Pick a time range large enough that each query takes a second or more. You can also throttle the network in dev tools. Click "Refresh dashboard", or turn on live refresh. Watch the tiles while the queries run. The time chart pulses. The number, tab

What happened? A time chart with a positive Series Limit picks its top N groups from the newest query chunk only. By default that chunk is the last 15 minutes of the range. A group that was busy earlier but quiet at the end drops off the chart, even if it was the biggest series in the range. On a 24h or 7d chart this can hide exactly the spike you are looking for. The docs say something different: The Series Limit field in Display Settings says it keeps "those with the largest values". The MCP/API schema says it "keeps the top-N groups by aggregated value over the queried range". Nothing tells the user that "largest" only covers the last few minutes. What should happen: the top N groups are ranked over the whole chart range, as the docs describe. At minimum, the UI and API docs should say how the ranking works. Steps to reproduce Use the default otel_logs schema. Insert logs for ServiceName = 'svc-a', 10,000 rows spread over 23 hours starting 24 hours ago, and none in the last hour.

Selecting a map attribute as a column labels it with the raw ClickHouse function form. A user who adds LogAttributes['constructor.index_builder_ac_res_id'] gets a results-table header reading: arrayElement(LogAttributes, 'constructor.index_builder_ac_res_id') At our column widths that header is wider than the value it sits over, and several such columns make the table unreadable. The same string shows up in the SELECT box and in chart legends. Cause. The generated SQL emits the subscript expression with no alias, so ClickHouse names the result column with the canonical function form. That naming is ClickHouse behaviour, not a bug — it happens for any unaliased Map subscript: DESCRIBE (SELECT LogAttributes['constructor.index_builder_ac_res_id'], ResourceAttributes['service.name'] FROM otel.otel_logs LIMIT 0) arrayElement(LogAttributes, 'constructor.index_builder_ac_res_id') String arrayElement(ResourceAttributes, 'service.name') String

What happened? A saved search scoped via the filter bar (the filters array) instead of the where clause evaluates its alerts correctly — the threshold count respects the filters — but the sample events rendered into the notification body are queried without the filters. The alert fires saying "1 lines found" and then shows five arbitrary, unrelated log lines from the time window as evidence (in our case: Kubernetes reloader/info noise with empty service fields, while the actually-matched event was a service error). Expected: the sample lines come from the same row set the alert counted — the sample query should apply savedSearch.filters the same way evaluation does. Cause: the two paths build their queries differently. Alert evaluation (packages/api/src/tasks/checkAlerts/index.ts, getChartConfigFromAlert) passes filters: savedSearch.filters into the shared buildSearchChartConfig — per its own comment, so all paths assemble configs "identically". The sample fetch (packages/api/s