Dashboards & Analytics · Data Freshness

Dashboard Data Freshness Checks

Freshness checks layered onto existing dashboards so a stale or stalled feed shows a clear warning instead of quietly serving old numbers as if they were current.

Start a ProjectAll Case Studies
3 to 6 days
build time
4
outcomes
5
stack tools
6
build steps

Built with real HMX dashboard tool paths

Supabase Postgrespg_cron (scheduled freshness checks)SQL freshness/lag viewNext.js 16 server componentsMetabase (last-updated indicators)Supabase Postgrespg_cron (scheduled freshness checks)SQL freshness/lag viewNext.js 16 server componentsMetabase (last-updated indicators)

01 // Outcomes

Outcome signals

Every
dashboard shows a clear 'data as of' stamp
Stale
feeds throw a warning instead of lying
Scheduled
lag checks via pg_cron, not on-load only
Agreed
freshness thresholds per data source

Case architecture

Dashboard Data Freshness Checks Architecture

6 nodes
List every data source a
a freshness check that
Supabase Postgres
pg_cron
Review Queue
Dashboard Action
  1. 01List every data source a

    Freshness checks layered onto existing dashboards so a stale or stalled feed shows a clear warning instead of quietly serving old numbers as if the...

  2. 02a freshness check that

    Add a freshness check that records each source's last-updated timestamp and computes lag.

  3. 03Supabase Postgres

    Supabase Postgres contributes the trusted model for Dashboard Data Freshness Checks so metrics are defined before they are visualized.

  4. 04pg_cron

    Schedule the check with pg_cron so freshness is measured continuously, not on page load only.

  5. 05Review Queue

    When automation confidence is low, route the record to a manual owner with the source, stage, and last action attached.

  6. 06Dashboard Action

    Every dashboard shows a clear 'data as of' stamp; Stale feeds throw a warning instead of lying; Scheduled lag checks via pg_cron, not on-load only;...

Problem

The operating gap

A dashboard that silently stops updating is worse than no dashboard — the team keeps trusting yesterday's numbers because nothing tells them the feed stalled, and decisions get made on stale data.

Build

What gets built

A freshness layer that records each data source's last-updated timestamp, compares it against an expected cadence, and renders an explicit 'as of' stamp plus a stale warning when a source falls behind. A scheduled pg_cron check can record freshness so the warning is driven by real lag, not assumption.

Build steps

How it ships

Dashboard Data Freshness Checks uses a reporting model and review layer for Dashboards. Freshness checks layered onto existing dashboards so a stale or stalled feed shows a clear warning instead of quietly serving old numbers as if the... The architecture connects list every data source a, supabase postgres, pg_cron, and dashboard action with an explicit control path.

  1. 01List every data source a dashboard depends on and its expected update cadence.
  2. 02Add a freshness check that records each source's last-updated timestamp and computes lag.
  3. 03Schedule the check with pg_cron so freshness is measured continuously, not on page load only.
  4. 04Render an explicit 'data as of' stamp on each dashboard plus a visible stale warning past threshold.
  5. 05Decide the stale thresholds per source with the operator so warnings are meaningful.
  6. 06Document the cadences and thresholds so freshness expectations are shared.

Stack

Tools and layers

  • Supabase Postgres
  • pg_cron (scheduled freshness checks)
  • SQL freshness/lag view
  • Next.js 16 server components
  • Metabase (last-updated indicators)
  • Inputs layer: List every data source a dashboard depends on and its expected update cadence.
  • Transform layer: Add a freshness check that records each source's last-updated timestamp and computes lag.
  • Metrics layer: Supabase Postgres contributes the trusted model for Dashboard Data Freshness Checks so metrics are defined before they are visualized.
  • Visualization layer: pg_cron (scheduled freshness checks) handles refresh, review, or reporting delivery while a freshness layer that records each data source's last-updated timestamp, compares it against an expected cadence, and renders an explicit 'as of'...
  • Action layer: Every dashboard shows a clear 'data as of' stamp; Stale feeds throw a warning instead of lying; Scheduled lag checks via pg_cron, not on-load only;...

Data flow

  1. 01List every data source a dashboard depends on and its expected update cadence.
  2. 02Add a freshness check that records each source's last-updated timestamp and computes lag.
  3. 03Schedule the check with pg_cron so freshness is measured continuously, not on page load only.
  4. 04Render an explicit 'data as of' stamp on each dashboard plus a visible stale warning past threshold.
  5. 05Decide the stale thresholds per source with the operator so warnings are meaningful.
  6. 06Document the cadences and thresholds so freshness expectations are shared.

Controls

  • A dashboard that silently stops updating is worse than no dashboard — the team keeps trusting yesterday's numbers because nothing tells them the fe...
  • A freshness layer that records each data source's last-updated timestamp, compares it against an expected cadence, and renders an explicit 'as of'...
  • When automation confidence is low, route the record to a manual owner with the source, stage, and last action attached.

Research basis