Data observability answers a simple question: Can I trust this data? When a dashboard shows unexpected numbers, you need to know if it’s a real business trend or a broken pipeline. When an executive asks about yesterday’s revenue, you need confidence that the data is fresh and complete. Data observability gives you that confidence.Documentation Index
Fetch the complete documentation index at: https://docs.anomalyarmor.ai/llms.txt
Use this file to discover all available pages before exploring further.
The Problem
Data pipelines fail silently. Unlike application errors that crash loudly, data problems often go unnoticed until someone makes a bad decision:| Scenario | What Happened | The Cost |
|---|---|---|
| Marketing spends $50K on wrong audience | Pipeline dropped demographic column | Wasted ad spend, wrong targeting |
| CEO quotes wrong revenue in earnings call | ETL job failed, dashboard showed stale data | Stock price impact, credibility loss |
| Product team ships feature to wrong segment | Upstream table had schema change | Development time wasted, wrong launch |
The Building Blocks
AnomalyArmor monitors data through these interconnected concepts:
Assets
Tables, views, and other data objects that AnomalyArmor monitors
Discovery
How AnomalyArmor finds and catalogs your data assets
Schema Changes
Detecting and tracking structural changes to your data
Freshness
Monitoring when your data was last updated
Metrics
Tracking statistical properties and detecting anomalies
Alerts
How you get notified when issues occur
Report Badges
Embedded status indicators for dashboards and docs
Intelligence
AI-powered search and documentation
Tagging
Classifying and organizing your assets
How They Work Together
Discovery scans your databases and catalogs Assets (tables, views, columns). Once cataloged, AnomalyArmor monitors each asset for:- Schema changes: Columns added, removed, or type-changed
- Freshness violations: Data not updated within your SLA
- Metric anomalies: Unexpected changes in row counts, null rates, or distributions
Quick Reference
| Concept | Question It Answers | Example Alert |
|---|---|---|
| Asset | What data do I have? | (Cataloging, no alert) |
| Discovery | What changed since last scan? | ”New table detected: staging.orders_v2” |
| Schema Change | Did the structure change? | ”Column removed: orders.shipping_status” |
| Freshness | Is data up to date? | “orders table is 4 hours stale” |
| Metric | Is data quality normal? | ”Row count dropped 60% from yesterday” |
| Alert | Who needs to know? | (Routes to Slack, PagerDuty, etc.) |
| Report Badge | Can consumers trust this? | (Visual indicator on dashboards) |
| Intelligence | Where is X data? | (AI-powered search result) |
| Tagging | What category is this? | (Classification: PII, production, etc.) |
Common Questions
What is data observability and how is it different from data quality?
Data observability is continuous visibility into data health: schema, freshness, row counts, distributions. Data quality is often a one-time or batch check (is this value in the expected set?). Observability catches problems as they happen - including ones you didn’t predict - while quality checks validate specific known rules. AnomalyArmor does both: observability by default, rule-based quality checks layered on top.Do I need to configure every monitoring concept manually?
No. Schema drift and freshness are automatic once discovery runs - no per-table setup. Metrics and custom rules are opt-in where you want them. Most customers get value from the automatic monitoring on day one and add explicit metrics to their most critical tables over the first week.How does AnomalyArmor decide what’s anomalous without me defining thresholds?
For metrics, AnomalyArmor builds a statistical baseline from 7-14 days of historical values and flags new readings outside that baseline’s expected range. For schema changes, “anomalous” is literal - the structure differs from the previous discovery. For freshness, it learns your typical update cadence and alerts when a table misses it.Can I start with just one concept and add others later?
Yes. The most common starting point is schema drift + freshness on production databases - zero-config, high signal. Add metrics and report badges once the alerting cadence is calibrated. Tagging and compliance usually follow.Next Steps
Connect Your Database
Start monitoring in under 15 minutes
Explore Assets
Understand the foundation of data observability