Low Dashboards system

Data Freshness & Staleness Check

A freshness panel that watches the heartbeat of each data source feeding the dashboards — last lead, last subscriber, last booking event, last blog change, last successful job — and flags any feed that hasn't updated within its expected window. It answers 'are the numbers I'm looking at current?' before anyone trusts a chart. This is the trust layer under every other dashboard in the suite.

Start a Project All Systems

3 to 5 days: timeline
Low: complexity
4: tools
4: steps

Built with real HMX dashboard tool paths

Supabase PostgresSQL (max timestamp / age)Next.js 16 server componentsTypeScriptSupabase PostgresSQL (max timestamp / age)Next.js 16 server componentsTypeScript

01 // System facts

System facts

Data Freshness & Staleness Check uses a reporting model and review layer for Dashboards. A freshness panel that watches the heartbeat of each data source feeding the dashboards — last lead, last subscriber, last booking event, last blog... The architecture connects list each tracked source and, supabase postgres, sql, and dashboard action with an explicit control path.

Outcome

Stops the worst dashboard failure mode — confidently acting on stale numbers. Owners get an explicit 'everything is current' (or 'leads feed is X hours stale') signal before they trust the rest.

Main risk

False alarms from business-hours/weekend gaps (no leads overnight is normal) cause alert fatigue and people start ignoring the staleness flag.

Prevention

Define per-source windows that account for business hours/expected cadence rather than a flat threshold, and separate 'expected quiet' from 'genuinely stale' in the UI.

Fallback

If per-source windows aren't tuned yet, show last-update ages as plain informational timestamps (no red/green) so owners self-judge, then layer thresholds once normal cadence is known.

System architecture

Data Freshness & Staleness Check Architecture

6 nodes

List each tracked source and

SQL that returns the latest

Supabase Postgres

SQL

Review Queue

Dashboard Action

01List each tracked source and
A freshness panel that watches the heartbeat of each data source feeding the dashboards — last lead, last subscriber, last booking event, last blog...
02SQL that returns the latest
Write SQL that returns the latest timestamp per source (max(created_at)/max(updated_at)) and computes age, mirroring the lastLead/lastWaitlist pattern already in lib/monitoring.ts.
03Supabase Postgres
Supabase Postgres contributes the trusted model for Data Freshness & Staleness Check so metrics are defined before they are visualized.
04SQL
Build a freshness strip (server component) showing each source with its last-update age and a stale/ok badge, sorted so stale sources float to the top.
05Review Queue
If per-source windows aren't tuned yet, show last-update ages as plain informational timestamps (no red/green) so owners self-judge, then layer thr...
06Dashboard Action
Stops the worst dashboard failure mode — confidently acting on stale numbers.

How it is built

Build steps

01List each tracked source and its max-allowed staleness (e.g. leads: a few hours in business time; monitoring jobs: per cadence; blog: days), as an explicit config.
02Write SQL that returns the latest timestamp per source (max(created_at)/max(updated_at)) and computes age, mirroring the lastLead/lastWaitlist pattern already in lib/monitoring.ts.
03Build a freshness strip (server component) showing each source with its last-update age and a stale/ok badge, sorted so stale sources float to the top.
04Add a single composite 'data is fresh' banner that turns amber/red if any critical source is stale, and surface it at the top of the main dashboard so stale data is never read as real.

Tools

Workflow surface

Supabase Postgres
SQL (max timestamp / age)
Next.js 16 server components
TypeScript

Inputs layer: List each tracked source and its max-allowed staleness (e.g. leads: a few hours in business time; monitoring jobs: per cadence; blog: days), as an explicit config.
Transform layer: Write SQL that returns the latest timestamp per source (max(created_at)/max(updated_at)) and computes age, mirroring the lastLead/lastWaitlist pattern already in lib/monitoring.ts.
Metrics layer: Supabase Postgres contributes the trusted model for Data Freshness & Staleness Check so metrics are defined before they are visualized.
Visualization layer: SQL (max timestamp / age) handles refresh, review, or reporting delivery while define per-source windows that account for business hours/expected cadence rather than a flat threshold, and separate 'expected quiet' from 'genuin...
Action layer: Stops the worst dashboard failure mode — confidently acting on stale numbers.

Data flow

01List each tracked source and its max-allowed staleness (e.g. leads: a few hours in business time; monitoring jobs: per cadence; blog: days), as an explicit config.
02Write SQL that returns the latest timestamp per source (max(created_at)/max(updated_at)) and computes age, mirroring the lastLead/lastWaitlist pattern already in lib/monitoring.ts.
03Build a freshness strip (server component) showing each source with its last-update age and a stale/ok badge, sorted so stale sources float to the top.
04Add a single composite 'data is fresh' banner that turns amber/red if any critical source is stale, and surface it at the top of the main dashboard so stale data is never read as real.

Controls and fallbacks

False alarms from business-hours/weekend gaps (no leads overnight is normal) cause alert fatigue and people start ignoring the staleness flag.
Define per-source windows that account for business hours/expected cadence rather than a flat threshold, and separate 'expected quiet' from 'genuin...
If per-source windows aren't tuned yet, show last-update ages as plain informational timestamps (no red/green) so owners self-judge, then layer thr...

Research basis