Feature Proposal: State Timeline Panel Type

[MikaelEngvall]

Problem

When monitoring service health status across multiple services, the current panel types don't work well:

• Time Series (line/bar): Overlapping lines for 20+ services are unreadable on a single graph
• One panel per service: Works visually but creates 20+ panels — heavy dashboards, hard to maintain
• Table: Shows only the latest value, losing the time dimension entirely

Grafana solves this with its "State Timeline" panel — a compact swim-lane visualization where each series is a horizontal row with color-coded segments over time. SigNoz currently has no equivalent.

Proposed Solution

A new panel type (state_timeline) that renders grouped time-series data as horizontal swim-lane rows with configurable value-to-color mappings:

State Timeline mockup — each row is a service, color indicates status over time (green = passed, yellow = intermittent, red = failed)

Each row represents a service. Green = passed, yellow = intermittent, red = failed. Time flows left to right.

Key behaviors:

• Each unique value of the group-by label becomes a row
• Time segments are color-coded based on configurable thresholds — not just binary. For example:
  • ≥ 0.999 → Green (Passed)
  • 0.001 – 0.999 → Yellow (Intermittent)
  • ≤ 0.001 → Red (Failed)
• Users define threshold ranges and map them to colors (supporting 2, 3, or more states)
• Hover tooltip shows timestamp, series name, exact value, and state label
• Works with existing query builder — no new query type needed

Use cases:

• CI/CD health-check pass rates across services
• Deployment status per environment
• SLO compliance tracking (met / degraded / breached)
• Any metric where discrete states over time matter more than exact values

Why This Matters

This is a common pattern for infrastructure and CI/CD monitoring. Many users migrating from Grafana expect this visualization. The current workaround (one panel per service) doesn't scale beyond 5-10 services.

Technical Scope

• Frontend only — no backend changes required
• New React component in frontend/src/container/
• Reuses existing time-series data format (same aggregation + group-by)
• Panel type registered as state_timeline
• Threshold configuration stored in widget JSON (similar to existing threshold support in other panels)

Willingness to Contribute

I'm happy to implement this and submit a PR if the team is interested. I'd appreciate guidance on:

• Preferred component patterns / design system conventions
• Whether there's an existing panel type I should use as a scaffold
• Any planned panel architecture changes I should be aware of

[MikaelEngvall]

How does it work here?
How do we proceed?
There is a PR at #12608
and the comments says we should agree on the design here.
I am aware of the fact that my PR is not possible to move forward with since it is built against the v1 dashboard code, which no longer renders dashboards.
I can amend the PR accordingly but I am waiting for the agreement of the design.

[MikaelEngvall]

Update: I've reworked the implementation on PR #12608 to fit the current v2 (Perses-based, v5-query) dashboard architecture, following @ahrefabhi's review. Posting the design decisions here so we can settle them before the PR is reviewed in depth.

What changed since the proposal

The original proposal said "frontend only, no backend changes." That turned out to be incorrect for the current architecture. In v2, a panel kind is a Perses plugin whose spec lives in the backend (pkg/types/dashboardtypes) and is code-generated into the frontend API types. So the port does touch the backend — but only to declare the panel spec, not the query path.

Summary of the implementation:

• Backend spec — new PanelPluginKind signoz/StateTimelinePanel plus a StateTimelinePanelSpec (visualization / formatting / legend / thresholds), wired into the panel plugin discriminated union in dashboardtypes. Options and thresholds live in plugin.spec, matching TimeSeriesPanelSpec.
• Frontend registration — a kinds/StateTimelinePanel/ folder (definition + renderer + sections) under DashboardPage/DashboardContainer/Panels/, registered in registry.ts, modelled on the freshly-added AreaChartPanel.
• Presentational components — the swim-lane row, segment, time axis, tooltip and label column now live under lib/visualization/charts/StateTimeline/ (the container/DashboardContainer/visualization/ path from the earlier review no longer exists on main).
• Data path — the transform was rewritten from the legacy QueryDataV3 shape to the v5 PanelSeries flow the v2 renderers consume.
• No query-service changes — v2 dashboards go through the v5 query API, so the panel kind doesn't touch query building. The earlier v3/v4 edits (IsGraphLike() etc.) were dropped.
• The branch was rebased onto main, so the diff is only this feature.

Decisions I'd like your input on

These are the choices I made to keep the port minimal. Two of them are genuine design calls, not mechanical ports:

1. Thresholds vs value-mappings (the main open question). The proposal described range-based value-to-color mappings (≥ 0.999 → Green, 0.001–0.999 → Yellow, ≤ 0.001 → Red). I implemented this using the existing ThresholdWithLabel shape (value + color + label) that Time Series / Area / Bar already use, with band semantics: a point takes the color of the highest threshold whose value is ≤ the point value. So {0 → Red "Fail"}, {1 → Green "Pass"} colors 0 red and 1 green.

   • Pro: reuses the existing threshold editor and spec shape; no new UI or backend type.
   • Con: it's "≥ boundary" bands, not arbitrary ranges with both bounds. The exact 0.001–0.999 interval example isn't directly expressible as a closed range — it's approximated by two boundaries.
   • If you'd prefer a dedicated value-mapping type (explicit ranges / discrete-value → color, closer to Grafana's value mappings), that's a larger change (new spec type + new editor variant) and I'd rather agree on it here first. It can also be added later without breaking the threshold-based version.

2. PANEL_TYPES mapping. I mapped signoz/StateTimelinePanel to the existing PANEL_TYPES.TIME_SERIES rather than adding a new enum value, since it issues a plain time_series query and adding a new value ripples into the query-builder / alert surfaces that switch on PANEL_TYPES. Happy to add a distinct value instead if you'd rather it be first-class there.

3. Kind name signoz/StateTimelinePanel, per your earlier suggestion.

Testing

Unit tests cover the v5-retargeted transform, the band-threshold evaluator, the time-axis tick logic, and legend interpolation. The property-based and component/render tests from the earlier version were not ported — several of them tested the old operator-based threshold algorithm and the v1 registration path, which no longer exist. I can add property-based tests for the band semantics if you'd like that level of coverage.

Happy to adjust any of the above — especially #1 — before you spend review time on the PR.

[MikaelEngvall]

Tested localy with real data (downloaded)

[ahrefabhi]

Ran this locally against the Storybook stories. I haven't reviewed the PR fully yet — will do a proper pass — but wanted to flag the rendering approach early since it may change a fair bit of the code.

Each segment is its own absolutely-positioned

with its own onMouseEnter/onMouseLeave (StateSegment.tsx). Segments only merge when consecutive values land in the same threshold band, so on realistic data almost nothing merges — TwoMonthsManyThresholds (60 days @ 30m × 6 services) puts ~17k DOM nodes and ~17k listeners on the page. It's visibly laggy, and the 0.3% min-width means the segments overlap into a barcode anyway, so the DOM cost buys nothing at that density:

Suggestion: draw the lanes on a canvas instead. One per panel, fill rects per segment, and handle hover with a single pointer listener + a binary search over segment start times to find what's under the cursor. That's O(1) DOM nodes and listeners regardless of data volume, and it also lets you drop sub-pixel segments or coalesce them per column instead of forcing a min width.

The repo already depends on uplot (1.6.31) and the sibling panels under lib/visualization/charts/ build on it, so a uPlot draw hook is one option and keeps axis/cursor/time-window behaviour consistent with the other panels — but a plain is fine too if uPlot's series model doesn't fit swim lanes well.

From a quick skim the v2 wiring (definition/registry/capabilities, plugin.spec on the Go side) looks like the right shape — I'll come back with detailed comments. Also worth rebasing, the branch currently conflicts with main.

[MikaelEngvall]

Thanks for profiling this — you're right, and it's the correct call to flag it before a full review.

The per-segment <div> + per-segment listeners come straight from the original v1 components; I ported the presentation mostly as-is and only re-pointed the data layer at v5. So the rendering model is exactly the part that should change, and your ~17k-nodes/17k-listeners measurement on TwoMonthsManyThresholds matches what I was already seeing: at real density the min-width forces a barcode, so the DOM cost buys nothing.

Canvas is clearly the right direction. Before I rewrite the render layer I'd like to pick the approach with you so it's done once:

1. uPlot draw hook — keeps axis / cursor / time-window behaviour consistent with the sibling lib/visualization/charts/ panels, and reuses the existing uplot dependency. Cost: bending uPlot's series model (built for lines/bars) to swim lanes.
2. Plain <canvas> — a single canvas per panel, fill-rect per segment, one pointer listener + binary search over segment start times for hit-testing. Simplest fit for lanes specifically; drops sub-pixel segments / coalesces per column instead of a min-width. Cost: it's outside the uPlot cursor/axis machinery, so time-axis and drag-zoom would be hand-rolled (the panel already hand-rolls those today).

The data/threshold/time-axis utils and the v2 wiring stay either way — it's the presentation that swaps. My lean is plain canvas since uPlot's model doesn't map cleanly to discrete state bands, but you clearly know the sibling panels' constraints better than I do, so I'd rather follow your preference here.

Two smaller things while I have you:

• Rebased onto latest main just now, conflicts resolved (the openapi.yml conflict was a generated-file artifact; regenerated from the Go spec so it's back in sync).
• On hover/hit-testing: a single-listener + binary-search approach also fixes the duration question from earlier in this thread — segment bounds are already data-derived, so the tooltip stays correct independent of the canvas rendering.

Happy to start on the canvas rewrite as soon as you've weighed in on 1 vs 2. Thanks again for the detailed look.