Metaplane Data Observability

Metaplane data testing

Metaplane is monitor-first, not test-first: it compares tables across sources, but it doesn't run rule-based tests on tables or DataFrames, or show failing rows.

• Table Comparison Tests: Source-to-Target Monitors compare aggregate metrics (row count, nullness, mean, etc.) between two tables or columns across the same or different databases to detect pipeline discrepancies (docs).

• SQL Table Tests: Metaplane provides anomaly-detection monitors (row count, freshness, nullness, uniqueness, mean, stddev, custom SQL) with optional manual thresholds, but there are no rule-based assertion-style checks covering completeness/uniqueness/validity/accuracy/referential-integrity/freshness assertions like dbt tests (docs).

• DataFrame Tests: Metaplane is a SaaS data observability platform that connects to warehouses and databases; no Python DataFrame (Pandas/Spark/Polars) in-memory testing library is provided (docs).

• Unstructured Data Tests: No LLM-based validation of free-text or JSON columns is mentioned in Metaplane's documentation (docs).

• Data Diff: Source-to-Target Monitors compare aggregate metrics between two tables, not individual rows; no row-by-row diff surfacing individual differing records is documented (docs).

• Data Contracts: No machine-readable data contract feature (producer-consumer schema and quality SLA in YAML/JSON Schema) is documented; Monitors-as-Code is YAML for configuring monitors, not a contract system (docs).

• Inspect Failed Rows: Metaplane tracks metric time series and surfaces anomalous observations, but there is no feature to surface actual failing rows in the UI (docs).

Metaplane data observability

ML models learn dynamic thresholds with tunable sensitivity, Group By monitors split metrics by segment, and you declare monitors in the UI or in dbt YAML. It also tracks dbt job durations.

Compare: data observability tools

• Data Profiling: Metaplane collects table and column statistics (row count, nullness, uniqueness, min, max, mean, stddev, cardinality) as part of its monitor observations, and provides usage analytics on table and column query history (docs).

• Anomaly Detection: Metaplane trains ML models on historical observations to set dynamic thresholds, with tunable sensitivity and optional model-data start date; users can provide feedback to tune the models over time (docs).

• Freshness Monitors: Freshness monitors track the time since a table or column was last updated, using information_schema metadata or MAX(column) queries, and alert when updates are overdue (docs).

• Volume Monitors: Row Count monitors track the number of rows in a table over time and alert when the count is anomalously higher or lower than expected (docs).

• Schema Monitors: Metaplane provides configurable schema change alerts that detect column additions, removals, renames, and type changes (docs).

• Field Monitors: Column-level monitors (nullness, uniqueness, cardinality, min, max, mean, stddev, sum, percent zero, percent negative) track metrics per column as time series and alert on anomalies (docs).

• Distribution Monitors: Cardinality and uniqueness monitors track column value distributions over time, and standard deviation monitors capture spread; no explicit histogram/percentile drift monitor is named, but column metric tracking enables distribution monitoring (docs).

• Segment Monitors: Group By monitors break down any standard monitor by one or more dimension columns, tracking each segment independently with its own anomaly model (docs).

• Custom SQL Monitors: Custom SQL monitors allow arbitrary SQL queries whose scalar or row-count output is tracked over time with ML or manual anomaly detection (docs).

• Partition-Based Monitors: Rolling time window filters add a WHERE clause to monitor only a specific date partition (e.g. last day) rather than scanning the full table (docs).

• UI-Based Monitors: Monitors can be fully created and configured through the Metaplane web UI without writing any code (docs).

• Monitors-as-Code: Monitors can be defined and deployed as YAML in dbt model metadata; when Metaplane syncs the dbt connection it automatically creates, updates, and disables monitors declared in the YAML (docs).

• Pipeline Monitoring: dbt Job Duration Monitors track job run times over time with anomaly detection, alerting when pipeline execution times degrade (docs).

• Window-Based Monitors: Metaplane's rolling time window filter adds a WHERE clause to scope the scan to recent rows (e.g. last 24h) — identical to the partition filtering approach documented under Partition-Based Monitors. This limits data scanned but does not evaluate metrics per time bucket (e.g. separate row-count per day); no tumbling or sliding window metric evaluation is documented (docs).

Metaplane incident management

Metaplane has a full incident workflow: alerts, triage, feedback, resolution, ticketing and on-call integrations.

• Alert Notifications: Metaplane sends incident alerts to Slack, Microsoft Teams, and email, with configurable alert routing and tag-based channel assignment (docs).

• Incident Triage: Incidents automatically group related failing monitors; users can assign owners, add labels, and filter by status, source, or tag (docs).

• Alert Feedback: Users can mark any failing observation as 'normal' from Slack or the UI to provide feedback to the ML model, reducing future false positives on similar data points (docs).

• Incident Resolution: Users can mark individual monitors or entire incidents as resolved (normal) from the incident page or directly from Slack alerts (docs).

• Ticketing Integrations: Jira integration allows creating Jira issues directly from Metaplane incidents with bidirectional links between the incident and the Jira ticket (docs).

• On-Call Integrations: PagerDuty integration creates a PagerDuty incident when a Metaplane incident opens, updates the title as monitors are linked, and resolves the PagerDuty incident when the Metaplane incident resolves (docs).

Metaplane data quality analytics

Metaplane's dashboards and health scores track data quality.

• Data Quality Dashboards: Metaplane provides customizable dashboards with charts showing monitor statuses, incident summaries, health scores, trends, and collections of critical tables (docs).

• Data Health Scores: Tables display health scores based on monitor pass/fail status, visible in the dashboard collections and table views (docs).

• Incident Resolution Metrics: Incidents groups failing monitors and supports labeling, owner assignment, and auto-resolve settings, but there is no documented MTTD/MTTR tracking, incident volume trend reporting, or resolution-rate-by-team analytics (docs).

Metaplane data lineage

Metaplane combines dbt manifests with column-level lineage parsed from the warehouse, end to end to BI dashboards, with impact analysis. It has no catalog or governance features.

Compare: data lineage tools

• Table-Level Lineage: Metaplane generates table-to-table lineage from dbt manifests and by parsing warehouse query logs (CREATE statements) (docs).

• Column-Level Lineage: Column-level lineage is built by parsing SQL CREATE statements in warehouse query history to identify direct and filter column dependencies (docs).

• End-to-End Lineage: Lineage spans ingestion tools (Fivetran), warehouse transformations (dbt), and downstream BI tools (Looker, Tableau, Mode, Sigma, etc.) in a single graph (docs).

• Impact Analysis: Data Impact Previews show downstream lineage affected by dbt model changes on PRs, and the lineage graph supports upstream/downstream traversal to assess incident blast radius (docs).

Metaplane FinOps

Metaplane tracks query performance and Snowflake compute spend, with anomaly detection on credit usage.

• Query Performance: Table/column usage analytics surface slowest queries and query execution time trends, helping identify expensive or degraded SQL patterns (docs).

• Cost Monitoring: Snowflake compute spend monitors track credit and compute usage over time with anomaly detection, and usage analytics identify costly tables and slow queries (docs).

Metaplane workflows

Metaplane has a REST API, webhooks and a dbt integration. Data CI/CD runs tests on dbt pull requests and posts the results as comments. It has no Python SDK.

• Scheduling: Monitors run hourly by default and support fully custom cron schedules configurable per-monitor or via account-wide defaults (docs).

• CI/CD Integrations: Data CI/CD with Data Test Previews runs automated tests on dbt PR schemas and posts results as PR comments, blocking or flagging changes before merge (docs).

• Webhooks: Metaplane supports HTTP webhook callbacks to external endpoints on incident open/resolve, with optional HMAC signature verification and configurable alert routing (docs).

• REST / GraphQL API: Metaplane provides a REST API with token-based authentication for triggering monitors, retrieving results, and bulk monitor creation (docs).

• dbt Integration: Metaplane integrates with both dbt Cloud and dbt Core to import manifest metadata, monitor job run durations, surface lineage, and enable Monitors-as-Code via dbt model metadata (docs).

• MCP Server: No Model Context Protocol (MCP) server is documented for Metaplane (docs).

• Python SDK: Metaplane provides a REST API and a CLI tool, but no pip-installable Python SDK is documented (docs).

Metaplane AI agents

Metaplane suggests monitors automatically. It has no AI chat, AI triage or MCP server.

• Automated Test Generation: Rules automatically add monitors to tables matching defined criteria (usage, schema, lineage) without per-table manual configuration; monitor suggestions are also surfaced based on query usage (docs).

• AI Chat Assistant: Metaplane has no in-product AI chat assistant; anomaly detection is backend-only and there is no conversational interface for users (docs).

• Natural Language Test Generation: Metaplane's custom SQL monitors require users to write SQL themselves; no AI/natural-language-to-monitor generation feature is documented (docs).

• AI Issue Triaging: Metaplane groups related incidents automatically by lineage and schema proximity but does not use AI/LLM to classify failures or surface root cause context (docs).

• AI Issue Resolution: No AI-driven remediation suggestions (SQL fixes, pipeline reruns, quarantine) are documented (docs).