Skip to content

Dashboard: server-side sparkline history endpoint for stat cards #197

Description

@unclesp1d3r

Context

Issue #162 ships dashboard sparklines using a client-side ring buffer (useSparkHistory hook) that accumulates the last ~20 dashboard-stats query results in memory. History resets on page reload and on project switch.

This is the right call for the initial delight pass -- no API surface changes, no migration, ships in one PR. But it means operators see flat sparklines for the first minute after loading the dashboard, and they lose context every time they navigate away.

Proposed Improvement

Add a series: payload to GET /api/v1/dashboard/stats (or a sibling endpoint GET /api/v1/dashboard/stats/series?window=1h) that returns time-bucketed historical counts for the four stat-card metrics (agents online, campaigns running, tasks running, total cracked).

This unblocks:

  • Sparklines that render meaningfully on first paint
  • Persistence across reloads and project switches
  • A longer time window than the 20-sample client buffer
  • Shared historical data for any future widget that wants it (uptime, throughput trends, queue depth)

Acceptance Criteria

  • New shared Zod schema in @hashhive/shared for the series payload ({ metric, points: { t: number; value: number }[] })
  • Backend route added to dashboard surface with @hono/zod-openapi, returning bucketed data from the events table (or a materialized rollup)
  • Frontend useSparkHistory swaps from ring-buffer-only to server-history-with-ring-buffer-tail: hydrate from server on mount, append live values from useDashboardStats invalidations
  • Bucketing strategy: 1h window with 1-minute buckets (configurable), zero-fill empty buckets
  • Stat-card sparkline renders with real history on first load (not flat)
  • Time-range selector on the trend chart (1h / 6h / 24h)

Dependencies

Why deferred from #162

The original #162 scope is purely visual-layer + new hook + new chart. Adding a new backend endpoint, shared schema, OpenAPI changes, and bucketing query is real cross-API-boundary work that warrants its own design and PR.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    • Status
      No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions