Now that you have discovery running and alerts configured, let’s set up completeness monitoring. This tracks row counts in your tables and alerts you when data volumes are abnormal.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.
What You’ll Accomplish
By the end of this step, you’ll have:- Completeness monitoring on a critical table
- ML-based anomaly detection learning your data patterns
- Alerts when row counts deviate from expected values
Why Completeness Monitoring?
Row count anomalies catch real problems:| Anomaly | What It Means |
|---|---|
| Sudden drop | Failed ETL job, data loss, broken pipeline |
| Unexpected spike | Duplicate loads, runaway inserts |
| Missing data | Source system outage, extraction failure |
| Gradual decline | Upstream issues, filtering bugs |
Set Up Monitoring
Navigate to Your Table
- Go to Assets from the main navigation
- Click on a table you want to monitor (pick one that receives regular data)
- Click the Completeness tab
Configure Settings
| Setting | Recommended Value | Why |
|---|---|---|
| Mode | Auto-learn | ML learns your normal patterns |
| Time Window | 24 hours | Matches daily ETL schedules |
| Check Interval | Hourly | Catches issues quickly |
| Sensitivity | 2 (Medium) | Balanced alerting |
Understanding the Learning Phase
After enabling, you’ll see a Learning status badge on the monitoring card. The chart will show data points being collected, with a message like “Building baseline - 3 of 7 data points collected.” What happens during learning:- Row counts are captured at your check interval
- ML model analyzes patterns (daily, weekly, hourly trends)
- After 7+ data points, predictions activate
After Learning Completes
Once the baseline is established:- Expected range shown on the chart
- Anomalies highlighted when row count falls outside predictions
- Alerts fire to your configured destinations
Explicit Mode (Alternative)
If you know exactly what to expect, use explicit mode:| Setting | Example |
|---|---|
| Mode | Explicit |
| Minimum Rows | 10,000 |
| Maximum Rows | 50,000 |
Which Tables to Monitor
Start with tables that:- Receive data regularly (daily, hourly)
- Are critical to downstream reporting
- Have predictable volume patterns
- Fact tables (orders, events, transactions)
- Staging tables from ETL pipelines
- Aggregation tables
- Dimension tables (change infrequently)
- Archive tables
- Temporary/scratch tables
Troubleshooting
Still in 'Learning' after a week
Still in 'Learning' after a week
Check these:
- Is the table receiving new data?
- Is the check interval appropriate for your data frequency?
- View the history tab to see if captures are running
Too many alerts
Too many alerts
Reduce noise:
- Increase sensitivity (3 or 4 = fewer alerts)
- Adjust time window to match your data patterns
- Consider if this table has irregular patterns
Not getting alerts when expected
Not getting alerts when expected
Verify:
- Learning phase is complete
- Alert rules are configured for completeness events
- Check the history tab to see detected anomalies
Common Questions
How long does AnomalyArmor’s anomaly detection take to start catching issues?
Usually 7-14 days of learning before anomaly detection is meaningful. During learning, AnomalyArmor records values without firing alerts so it can establish a baseline. You’ll see a Learning status on the metric until the baseline is stable.Why is my metric stuck in ‘learning’ status?
Learning needs enough historical data points to build a baseline - typically 14 daily samples or 30+ hourly samples. If your table is new or only sampled sporadically, learning takes longer. Reduce the sampling interval temporarily to accelerate, then relax it once anomaly detection is active.Can I use AnomalyArmor for row-count monitoring on massive tables without full scans?
Yes - AnomalyArmor usesCOUNT(*) only, which most databases satisfy from statistics or indexes without a full scan. For very large tables where even COUNT(*) is expensive, you can monitor a partitioned slice (e.g., created_at >= NOW() - INTERVAL '1 day') as a lightweight proxy.
What’s the difference between row-count monitoring and freshness monitoring?
Row counts detect volume anomalies (sudden drops, spikes) regardless of whether new rows are landing. Freshness detects staleness - was the most recent row added within your SLA? Use both: freshness alerts when the pipeline stops, row counts alert when it runs but produces wrong amounts.What’s Next
Column Metrics
Track null percentages, distinct counts, and more
Freshness Monitoring
Ensure tables are updated on schedule