Data Observ

Documentation

How Data Observ works - setup, monitoring, costs, billing, and your data.

What Data Observ does and the under-5-minute setup to your first monitored tables.

Getting started with Data Observ

Data Observ is a data observability platform that helps you monitor the health, quality, and performance of your data warehouse. It connects to your warehouse, runs lightweight read-only queries to collect metadata about your tables and columns - row counts, table sizes, data freshness, schema changes, and column-level statistics - then analyzes that metadata to detect anomalies and alert you to problems. It never stores your actual data.

Setup takes less than 5 minutes

  1. Sign up - no credit card required for the free tier.
  2. Connect your data warehouse using read-only credentials (see "Connecting a warehouse").
  3. Choose the tables you want to monitor (see "Choosing tables to monitor"). Your free tier covers up to 3 tables, forever.
  4. You're live. Monitoring runs automatically and the overview dashboard starts filling in with health, freshness, and anomaly trends.

The intuitive interface guides you through each step. You can add or remove monitored tables at any time.

Was this helpful?

How to connect Snowflake (or Postgres) with read-only credentials, and exactly which permissions we need.

Connecting a warehouse

Data Observ connects to your warehouse with read-only credentials and uses them only to run monitoring queries. We currently support Snowflake with full monitoring, alerting, and cost tracking. BigQuery, Amazon Redshift, and Databricks support is coming soon.

Use a dedicated, least-privilege role

Create a credential scoped to just the tables you want to monitor. We never need write, delete, or admin permissions. Specifically, we need to be able to:

  1. List schemas and tables
  2. Query table metadata (row counts, column info)
  3. Run SELECT queries for column statistics

That's it - no INSERT, UPDATE, DELETE, or account-admin rights.

How credentials are stored

Database credentials are encrypted at rest with AES-256 before storage, and decrypted only when needed to run a monitoring query. For Snowflake we also support key-pair authentication, and for AWS services we support IAM roles, for stronger security than a static password.

Networking note

Our monitoring jobs connect from a fixed NAT Gateway IP. If your warehouse enforces an IP allowlist (Snowflake network policies, security groups), add our egress IP - connection timeouts are almost always an allowlist issue, not an SSL problem.

Was this helpful?

How to pick tables, how the free 3-table tier works, and how monitoring frequency is set.

Choosing tables to monitor

After your warehouse is connected, Data Observ discovers your schemas and tables. You choose which ones to actively monitor - start with your most critical tables (the ones your dashboards, models, and customers depend on).

The free tier covers 3 tables

You can monitor up to 3 tables forever, free, with no credit card. You still get the full feature set on those tables: real-time monitoring, alerts, and historical trend analysis. It's perfect for trying Data Observ or watching just your most important tables. To monitor more, upgrade - it's $1 per table per month (see "Plans and billing").

Monitoring frequency

By default we run monitoring queries every hour. You can customize the cadence per table based on how critical it is - from every 15 minutes for your most important tables to once daily for less important ones, and you can schedule runs during off-peak hours.

Multiple environments

You can connect multiple data sources (dev, staging, production) within the same organization. Each source is monitored separately, with its own alert settings.

Was this helpful?

The default metrics applied to every monitored table - row count, freshness, schema changes, and column stats including null %.

Metrics explained

Every monitored table automatically receives a set of default metrics, calculated during each monitoring run. They help detect anomalies, track trends, and ensure data reliability with no extra configuration.

Table-level metrics

  • row_count - number of rows in the table during the time window (e.g. row_count = 1,247,891).
  • freshness - time since the last record was added, in seconds (e.g. freshness = 3600 is one hour ago). Stale data is one of the most common upstream-pipeline failures.
  • schema_changes - tracks changes to table structure: columns added, removed, or modified (e.g. Added column email_verified, removed column temp_flag).

Numeric column metrics

For numeric columns we track min, max, avg (average), stddev (standard deviation), and variance - so a shift in the distribution of a column (not just its row count) surfaces as an anomaly.

Text & string column metrics

For text columns we track min_length, max_length, and avg_length, plus the completeness signals:

  • nulls_count / nulls_percent - the number and percentage of NULL values in the column (e.g. nulls_percent(email) = 2.3%).
  • missing_count / missing_percent - NULL and empty-string values combined.

A spike in null % is usually the first sign an upstream join or source feed broke.

Was this helpful?

What anomalies Data Observ detects and how custom checks extend quality testing.

Anomaly detection

Data Observ analyzes each table's metric history to flag values that break from their normal pattern. Anomaly detection learns your data's patterns over time, which keeps false positives down.

What we detect

  • Unexpected row count changes (sudden growth or drop)
  • Data freshness issues (a table that stopped updating)
  • Schema changes (columns added, removed, or retyped)
  • Null value spikes and missing-data gaps
  • Value distribution changes and statistical outliers in your metrics
  • Duplicate records

Custom checks

Beyond the automatic metrics, custom checks let you define quality tests from a library of 90+ dbt-powered checks - not-null constraints, row-count expectations, uniqueness, accepted values, schema validation, anomaly detection, and more. Results are tracked over time on your overview dashboard with pass/fail trends per pillar, so you can see quality drift before it reaches a customer.

AI assistant

Data Observ includes an AI assistant that can answer questions about your data health, help investigate a specific anomaly, and recommend next steps based on your monitoring data.

Was this helpful?

How alerts work, which channels are supported, per-table thresholds, and reducing alert fatigue.

Alerts and notifications

Set up alerts on conditions like row-count changes, data freshness, null percentages, or value ranges. When a condition is met, Data Observ notifies you on your configured channels within minutes.

Notification channels

We currently support Email, Slack, and PagerDuty. You can configure multiple channels and route different alert types to different channels. Webhook support is coming soon.

Per-table thresholds

Each table can have its own monitoring rules and thresholds. For example, alert if Table A grows more than 10% but Table B grows more than 50% - everything is configurable per table.

Reducing alert fatigue

To keep alerts signal-not-noise, Data Observ provides:

  • Smart grouping of related alerts
  • Customizable alert frequencies
  • Business-hours settings
  • Anomaly detection that learns your data patterns to cut false positives
Was this helpful?

Define quality tests on your tables from a library of 90+ dbt-powered checks.

Custom checks

Custom checks let you go beyond the automatic default metrics and define your own quality tests on any monitored table, from a library of 90+ dbt-powered checks.

What you can test

  • Not-null constraints
  • Row-count expectations
  • Uniqueness
  • Accepted values (the column only contains values from an allowed set)
  • Schema validation
  • Anomaly detection
  • ...and more

How results show up

Results are tracked over time on your overview dashboard with pass/fail trends per pillar, so you can watch quality drift and catch a regression before it reaches a dashboard or a customer. You configure which metrics to track, set custom thresholds for alerts, and choose which columns to monitor.

Was this helpful?

Monitor Supabase, AWS and more - not just data warehouses.

Platform integrations

Beyond data warehouses, DataObserv monitors the platforms your data runs on - Supabase, AWS, and more. A platform integration is a read-only connection that surfaces platform-native health: auth activity, database pressure, storage, cost, and security posture.

Where to see it

Connected platforms appear under Platforms in the sidebar:

  • Overview - one comparable health card per platform (status, score, open alerts, advisories).
  • Per-platform drill-in - the platform's native detail (Supabase auth/storage/advisors; AWS cost/compute/security).

Alerts

Platform issues (a firing advisor, a public S3 bucket, connection pressure) fire into Anomalies & Alerts and the Overview alert feed, exactly like table anomalies. Nothing extra to configure.

Connect one

Settings → Add data source → pick Supabase or AWS and follow the in-app setup guide.

Was this helpful?

What DataObserv monitors in your Supabase project.

Supabase monitoring

Connect with your project ref, service_role key, and (recommended) a Management API token. DataObserv reads only - it never writes.

What we monitor

| Group | Tracks | |---|---| | Auth | users, active sessions, login/signup/token activity | | Database health | size, connections, cache hit ratio, deadlocks, rollbacks | | Infrastructure | CPU load, memory, disk usage | | Storage | buckets, objects, bytes | | Query stats | top queries by total time (pg_stat_statements) | | Advisors | Supabase security & performance lints (the highest-value signal) | | Logs | recent Postgres errors | | RLS | row-level-security coverage across public tables |

Getting the credentials

  • Project ref - Settings → General → Reference ID.
  • service_role key - Settings → API. Unlocks auth/storage/db/infra.
  • Management API token (sbp_...) - Account → Access Tokens. Unlocks advisors, logs, and SQL.

Security & performance advisors flag real issues - RLS gaps, unindexed foreign keys, mutable function search paths - and fire as alerts.

Was this helpful?

Comprehensive, read-only AWS observability - cost, infra, and security posture.

AWS monitoring

Connect via a cross-account IAM role that trusts DataObserv with an External ID. We use STS AssumeRole - we never see or store your AWS keys. Attach ReadOnlyAccess (or SecurityAudit + Billing).

What we monitor

Everything you run - services you don't use simply show as not-present:

  • Cost & billing - Cost Explorer (spend by service, forecast), Budgets, Cost Anomaly Detection.
  • Compute - EC2, EBS, Auto Scaling; Serverless - Lambda, API Gateway; Containers - ECS, EKS.
  • Database - RDS/Aurora, DynamoDB, ElastiCache, Redshift.
  • Storage - S3 (incl. public-bucket flags), EBS, EFS, Backup.
  • Networking - load balancers, CloudFront, Route53; Messaging - SQS/DLQ, SNS, Kinesis.
  • Security posture - IAM (root MFA, stale keys), GuardDuty, Security Hub, Config, CloudTrail.
  • Reliability - AWS Health events, CloudWatch alarms, Service Quotas.

Security posture is the differentiator

We alert on new GuardDuty findings, root accounts without MFA, public S3 buckets, stale access keys, and missing multi-region CloudTrail - turning AWS monitoring into a posture monitor, not just a metrics dashboard.

Setup

Settings → Add data source → AWS shows a copy-paste CloudFormation role snippet. Paste the role ARN, External ID, and regions, then Test connection.

Was this helpful?

How Data Observ tracks Snowflake compute, storage, and warehouse utilization.

Cost tracking

For Snowflake warehouses, Data Observ automatically tracks your spend so you can catch a runaway bill before it lands.

What's tracked

  • Compute credits consumed, by warehouse and over time
  • Storage costs
  • Warehouse utilization

On the Costs dashboard you can view cost trends, identify expensive queries, and set up cost alerts so a spike pages you instead of surprising you on the invoice. Cost tracking reads the same account-usage metadata as the rest of the platform - it never touches your table data.

Was this helpful?

The free 3-table tier, simple $1/table/month pricing, annual discount, and how to cancel.

Plans and billing

Data Observ pricing is deliberately simple.

Free tier

Monitor up to 3 tables forever, with no credit card required. You get the full feature set on those tables - real-time monitoring, alerts, and historical trend analysis.

Paid - $1 per table per month

To monitor more than 3 tables, upgrade to the paid plan: $1 per monitored table per month. You only pay for the tables you actively monitor, billed monthly based on how many tables are enabled. Add or remove tables anytime and we prorate the charges.

Annual billing

Pay annually for a 20% discount - $9.60 per table per year instead of $12. Contact sales for enterprise volume discounts.

Cancelling

You can cancel anytime, no questions asked. You keep access through the end of your current billing period, then your account reverts to the free tier (3 tables).

Was this helpful?

We store metadata, never your warehouse rows - encryption, read-only access, and our security baseline.

Data privacy and security

Security is the top priority, and the core design choice protects you by default: Data Observ never stores your actual data.

We store metadata, not your rows

We only store metadata about your tables - table names, column names, row counts, and statistical information (min/max values, averages, null counts). Your sensitive business data never leaves your data warehouse.

Security baseline

  • Read-only access. We only ever request read-only access to the tables you choose to monitor - never write, delete, or admin permissions.
  • Encryption in transit and at rest. All connections are encrypted with TLS 1.3; credentials are encrypted at rest with AES-256.
  • Strong auth options. Key-pair authentication for Snowflake and IAM roles for AWS services.
  • SOC 2 Type II security practices.
  • Multi-tenant isolation. Every tenant's data is isolated by organization, enforced with row-level security.

How credentials are handled

Database credentials are encrypted before storage and decrypted only when a monitoring query needs to run. We never log or expose decrypted credentials.

If you have questions about security or need a deeper review, contact support.

Was this helpful?

Still stuck? Contact support and our team will help.

    Chat with SalesGet instant help

    Cookie Preferences

    Manage your privacy settings

    We use cookies to enhance your browsing experience, serve personalized content, and analyze our traffic. By clicking "Accept All", you consent to our use of cookies. Read our Cookie Policy and Privacy Policy to learn more.

    Cookie Policy Privacy Policy Terms of Service