48.4k Log in Get started
Dashboard

What does a CDP sync health dashboard show in Metabase?

A CDP sync health dashboard shows whether customer data is actually flowing — event volume by source, sync success rates by destination, freshness against SLOs, and schema quality in one governed view. It's the observability layer for a stack built on Segment, RudderStack, Hightouch, or Customer.io, built from the run logs and metadata those tools already produce.

For: data engineers, marketing ops, and the growth teams whose audiences depend on the pipes. Grain: one row per sync run, plus daily event counts per source.

Which cards belong on a CDP sync health dashboard?

  • Hours since last successful sync by destination, vs. SLO (table)
  • Sync success rate by destination by week (line)
  • Events by source by day (stacked area)
  • Volume anomalies — today vs. trailing 28-day average (table)
  • Schema violations and blocked events by source (table)
  • Rows synced to activation tools by week (stacked bar)
  • Failed runs by error category, trailing 30 days (bar)
  • Identified vs. anonymous event share (line)

What data does the dashboard need?

  • cdp_sync_runs — one row per sync run: destination, started/finished timestamps, status, rows attempted and synced, error category.
  • event_volume_daily — one row per source per day, with allowed and blocked counts where the tool reports them.
  • Schema/tracking-plan violation counts per source per day, if enforced.
  • A small sync_slos table (destination, freshness SLO hours) so breach cards stay declarative.

How do you build it?

  1. Land run logs from each link in the chain: Hightouch's native hightouch_audit tables, Segment's Public API metadata, RudderStack's monitoring surface.
  2. Model them into one cdp_sync_runs table with consistent status and error categories, plus event_volume_daily per source.
  3. Add the SLO table, then build freshness, success-rate, and volume-anomaly cards with destination and source filters.
  4. Alert on SLO breaches and consecutive failures — not single transient errors.

Example card SQL

Success rate, rows, and duration by destination by weekPostgreSQL
SELECT
  destination,
  date_trunc('week', run_started_at) AS week,
  COUNT(*)                                     AS runs,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE status = 'success')
      / NULLIF(COUNT(*), 0), 2
  ) AS success_rate_pct,
  SUM(rows_synced)                             AS rows_synced,
  ROUND(AVG(EXTRACT(EPOCH FROM (
    run_finished_at - run_started_at
  ))), 0) AS avg_duration_seconds
FROM cdp_sync_runs
WHERE run_started_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY 1, 2
ORDER BY 1, 2;

Metrics

Sync success rateData freshnessActivation rate

Integrations

Segment + MetabaseRudderStack + MetabaseHightouch + MetabaseCustomer.io + Metabase

Dashboards

Marketing funnelEmail engagement

FAQ

Why monitor the CDP from Metabase instead of its own UI?
Each tool's UI shows its own slice. A customer data stack is usually a chain — events into Segment or RudderStack, a warehouse in the middle, Hightouch syncing audiences back out — and a failure anywhere breaks the whole promise. Landing every link's run log in the warehouse puts the chain on one dashboard, with history the UIs don't keep and joins they can't do.
What's the first card to build?
Hours since last successful sync, per destination, against a per-destination SLO — the data freshness pattern. It catches both loud failures and silent ones (paused schedules, empty runs), and it's the card that tells a marketer whether the audience they're about to message is current.
Where does the sync log data come from?
Three sources, often combined: native audit tables written to your warehouse (Hightouch's hightouch_audit.sync_runs), pipeline metadata APIs (Segment's Public API event-volume and sync endpoints), and the delivery/monitoring surfaces of the CDP itself (RudderStack). A small scheduled script landing each into one cdp_sync_runs model is usually a day's work.
Should event volume anomalies alert marketing or data teams?
Both, differently. A tracking breakage (volume cliff from one source) is a data-engineering page; the marketing-facing symptom — audiences shrinking, journeys not triggering — arrives days later. Volume-anomaly cards with a trailing-average baseline give the data team the early signal, and the annotation history explains later metric dips to everyone else.
How is this different from generic pipeline observability?
The grain is customer-data-specific: audiences, identity resolution, and activation destinations rather than arbitrary DAGs. If you run dbt or Airflow observability already, this dashboard complements it — it answers "did the suppression list reach the ad platforms today?", which no task-level view answers directly.