Data Platform Health Dashboard Template
A practical, implementable dashboard layout and widget catalogue to monitor ingestion success, pipeline latency, data freshness, schema changes, contract violations, consumer SLAs, and suggested alerting and ownership so teams detect problems early and route ownership to reduce downstream analytic failures.
Purpose and Hunger
This template helps platform teams detect platform problems early, understand impact, and route ownership so downstream analytics remain trustworthy. It focuses on ingestion, pipeline execution, freshness, schema/contract drift, and consumer-facing performance so you can stop silent failures and fix root causes before analysts make wrong decisions.
Dashboard Layout (Suggested)
Organize the dashboard into linked panes so operators and consumers can move from a high-level health view to actionable diagnostics:
- Platform Health Scorecard (top row) — single-row summary of availability, freshness, backlog, and quality.
- Pipeline Overview (middle left) — list of pipelines with success rate, recent latency percentiles, and error counts.
- Contract & Schema Panel (middle right) — contract violations, recent schema changes, and impacted consumers.
- Consumer Performance & SLAs (bottom left) — query/API latency, error rate, and SLA compliance by consumer team.
- Incidents & Alerts (bottom right) — active alerts, recent incidents, owners, and runbook links.
Widget Catalogue and Definitions
Platform Health Scorecard
- Availability: percent of scheduled ingestion jobs that completed successfully in the last 24 hours. Formula: (successful runs / scheduled runs) * 100.
- Freshness (max lag): maximum data age across critical datasets (e.g., minutes/hours since last successfully ingested partition).
- Backlog: number of unprocessed messages or partitions older than expected processing window.
- Data Quality Index: composite score combining schema conformity, missing-value rate, and contract violations (weighted).
Pipeline-level Widgets
- Success Rate (24h / 7d): rolling success percentage; allow filtering by pipeline and environment (prod/non-prod).
- Latency distribution: p50, p95, p99 of end-to-end run time and per-stage durations.
- Error types & counts: top error categories (e.g., connection, parsing, resource limits) with links to sample failing logs.
- Failed run list: most recent failed runs with start time, duration, error summary, and owner contact.
Data Contract & Schema Panel
- Contract violations: number of violations, recent examples with dataset, field, expected vs observed contract, and severity labels.
- Schema change detector: last N schema diffs, who committed them, and automated impact assessment (columns added/dropped/changed type).
Consumer-facing Performance
- Query/API latency (p95): by endpoint or dataset; highlight regressions vs baseline.
- Error/timeout rate: percent of failed requests or queries over threshold.
- Top consumers: queries or consumers producing the highest load or cost, with ability to drill into query text and explain plans.
Suggested Alert Thresholds and Response
Use graduated severity levels with clear owners and actions. Tune thresholds based on historical behaviour and business impact.
- Severity: P1 (Platform outage) — Availability < 90% across critical pipelines OR Backlog > 2× SLA window. Action: page on-call platform owner, open incident, runbook execution.
- Severity: P2 (Degraded) — Freshness lag > SLA but < 2× SLA OR data quality index drop > 20%. Action: notify pipeline owner, create ticket, investigate consumer impact.
- Severity: P3 (Warning) — single pipeline success rate drop > 5% vs baseline OR schema change detected without contract update. Action: email owners, track in dashboard.
Suggested notifications: P1 -> PagerDuty/Phone, P2 -> Slack + Ticketing, P3 -> Email + Dashboard note.
Ownership & RACI
Define clear ownership to avoid manual handoffs:
- Platform Owner (team): responsible for ingestion framework, metrics instrumentation, and on-call for P1 incidents.
- Pipeline Owner (team/individual): owns pipeline success, latency, and repair for their pipeline (P2/P3).
- Data Product / Consumer Owner: owns SLA definition and validates downstream impact; participates in escalations when consumers are impacted.
Exportable JSON Spec (Example Skeleton)
Provide an exportable widget list and query placeholders so teams can import into BI tools. Replace the example queries with your metrics source (metrics DB, events table, scheduler API).
{"dashboard": {"title": "Data Platform Health", "panes": [ {"id":"scorecard","widgets":[{"type":"metric","name":"availability","query":"","refresh":"5m"}]}, {"id":"pipelines","widgets":[{"type":"table","name":"pipeline_status","query":" ","columns":["pipeline","success_rate","p95_latency","errors"]}]} ] }}
Use this skeleton to generate JSON exports for your BI tool (Grafana, Looker, Superset, PowerBI).
Implementation Notes & Data Sources
- Metric sources: scheduler run table (Airflow/Chronos), metrics export (Prometheus), logs indexed in ELK, metadata/catalog (e.g., Data Catalog), lineage store, and query engine audit logs.
- Instrument early: ensure every pipeline emits start/end events, stage timing, error codes, and dataset identifiers.
- Lineage & context: link failing runs to lineage so you can show affected downstream datasets and consumers.
- Frequency & retention: refresh health metrics at least every 5–15 minutes for production; retain historical metrics for trend analysis.
- Security: restrict consumer performance panels to authorized teams; avoid showing PII in logs embedded in dashboard.
Drilldowns and Actions
- From any failed run, link to the pipeline run detail page, related logs, and the runbook for common fixes.
- From contract violations, provide sample offending rows and a quick link to a “replay” or backfill staging action if safe to run.
- From consumer SLA breaches, show top failing queries and a contact card for consumer team leads to coordinate remediation.
Onboarding Checklist
- Identify critical datasets and agreed SLAs (freshness, availability).
- Instrument pipelines to emit run metrics and error codes.
- Wire metrics into dashboard panels and validate queries.
- Configure alerts at P1/P2/P3 thresholds and assign owners.
- Run a simulated incident to validate escalation and runbooks.
Next Steps & Adaptation
Start simple: implement the scorecard and one pipeline panel, then iterate. Use this template as a living tool: tune thresholds, add additional metrics (resource usage, cost), and package the final version as a reusable domain or toolkit for other teams.
Discussion
Comments and conversation will live here.