Skip to main content

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.

Avoid these pitfalls when setting up AnomalyArmor. Most users encounter at least one of these. Here’s how to prevent and fix them.

​
Database Connection Mistakes

​
Wrong Port Number

The mistake: Using the wrong default port for your database.
DatabaseCorrect PortCommon Mistake
PostgreSQL54323306 (MySQL)
ClickHouse HTTPS84439000 (native)
ClickHouse HTTP81239000 (native)
Databricks443N/A
How to fix: Double-check the port in your database settings or cloud console.

​
SSL Not Enabled

The mistake: Not enabling SSL when your database requires it. Most cloud databases require SSL:
  • AWS RDS/Aurora: Required by default
  • Supabase: Required
  • ClickHouse Cloud: Always HTTPS
  • Google Cloud SQL: Required by default
How to fix: Set SSL Mode to require in your connection settings.

​
Forgot to Allowlist IPs

The mistake: Firewall or security group blocks AnomalyArmor. Symptoms:
  • “Connection refused” error
  • “Connection timed out” error
How to fix:
  1. Go to Settings → Security to find AnomalyArmor IPs
  2. Add them to your security group/firewall rules
  3. Test the connection again

​
Using Wrong Endpoint (AWS)

The mistake: Using the wrong RDS/Aurora endpoint. 
Common mistakes:
✗ mydb.rds.amazonaws.com (missing region)
✓ mydb.us-east-1.rds.amazonaws.com

✗ Writer endpoint for read-only operations
✓ Reader endpoint (recommended for monitoring)
How to fix: Copy the endpoint directly from AWS Console.

​
Permission Mistakes

​
Insufficient Database Permissions

The mistake: User can connect but can’t read metadata. Symptoms:
  • “Permission denied” error
  • Discovery finds no tables
Required permissions: 
-- PostgreSQL
GRANT CONNECT ON DATABASE your_db TO anomalyarmor;
GRANT USAGE ON SCHEMA public TO anomalyarmor;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO anomalyarmor;

-- ClickHouse
GRANT SELECT ON system.* TO anomalyarmor;
GRANT SELECT ON your_database.* TO anomalyarmor;
GRANT SHOW ON *.* TO anomalyarmor;

​
Forgetting Schema Permissions

The mistake: Granting table access but not schema access. 
-- Wrong: Has table access but not schema access
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO anomalyarmor;

-- Right: Add schema usage
GRANT USAGE ON SCHEMA analytics TO anomalyarmor;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO anomalyarmor;

​
Not Granting Access to Future Tables

The mistake: New tables aren’t automatically monitored. 
-- PostgreSQL: Grant access to future tables
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO anomalyarmor;
Without this, you’ll need to manually grant access each time a table is created.

​
Alert Configuration Mistakes

​
Alerting on Everything

The mistake: Creating broad rules that alert on every change in every environment. Result: Alert fatigue. Your team ignores all alerts. Better approach:
  1. Start with 5-10 critical production tables
  2. Alert only on breaking changes (column removed, table removed)
  3. Exclude dev/test environments
  4. Add coverage gradually

​
Same Destination for All Severities

The mistake: Sending all alerts to Slack or all alerts to PagerDuty. Result: Important alerts get buried or you get paged for trivial issues. Better approach: 
Critical (column removed)  → PagerDuty + Slack #incidents
High (type changed)        → Slack #data-alerts
Low (column added)         → Email digest

​
Too-Tight Freshness SLAs

The mistake: Setting freshness SLA to match exact expected timing. 
ETL runs hourly
SLA set to 1 hour
ETL occasionally takes 65 minutes
Result: Constant false positives
Better approach: 
ETL runs hourly
SLA set to 2 hours (2x expected)
Buffer for normal variation
Tighten later if needed

​
Not Disabling Rules During Maintenance

The mistake: Getting paged during planned maintenance. How to fix: Before maintenance:
  1. Go to Alerts → Rules
  2. Toggle OFF relevant rules
  3. Set a reminder to re-enable
  4. Toggle rules back ON after maintenance

​
Discovery Configuration Mistakes

​
Discovery Too Infrequent

The mistake: Daily discovery for production databases. Result: Schema changes aren’t caught until the next day. After pipelines fail. Better approach:
EnvironmentDiscovery Frequency
ProductionHourly
StagingEvery 6 hours
DevelopmentDaily

​
Not Scheduling Before Pipeline Runs

The mistake: Discovery runs at random times, not before pipelines. Better approach: 
Pipeline runs at: 3:00 AM
Discovery should run at: 2:00 AM

This way, you get alerts before the pipeline runs.

​
Including Unnecessary Schemas

The mistake: Monitoring schemas that change constantly. 
Schemas generating noise:
- pg_temp_* (PostgreSQL temp tables)
- test_* (test tables)
- *_backup (backup copies)
- dev_* (development)
How to fix: Add schema filters to exclude noisy schemas.

​
Freshness Monitoring Mistakes

​
Wrong Timestamp Column

The mistake: Using created_at for tables that get updated.
Table TypeRight Column
Append-only (events, logs)created_at
Updated tables (users, profiles)updated_at
ETL destination_loaded_at or _etl_timestamp
Symptom: Freshness shows stale even though data is current.

​
Not Handling Weekends

The mistake: Freshness SLA assumes 24/7 updates. Result: Weekend alerts for data that legitimately doesn’t update. Options:
  1. Longer SLA (72 hours for daily data)
  2. Disable rules on Friday, re-enable Monday
  3. Different weekend thresholds (coming soon)

​
Security Mistakes

​
Using Production Application Credentials

The mistake: Using the same credentials your application uses. Risks:
  • If compromised, attacker has full application access
  • Can’t easily rotate without affecting application
  • No audit trail separation
Better approach: Create a dedicated read-only user for AnomalyArmor.

​
Not Using SSL

The mistake: Disabling SSL “because it’s easier.” Risk: Credentials transmitted in plaintext. How to fix: Always use SSL Mode: require for production.

​
Checklist: Before Going Live

Use this checklist to avoid common mistakes: Connection:
  • Correct hostname (no typos)
  • Correct port for database type
  • SSL mode set to require
  • AnomalyArmor IPs allowlisted
Permissions:
  • Dedicated read-only user created
  • CONNECT granted on database
  • USAGE granted on schemas
  • SELECT granted on tables
  • Future table access configured
Discovery:
  • Discovery frequency matches environment (hourly for production, 6h for staging, daily for dev)
  • Scheduled before pipeline runs
  • Noisy schemas excluded
Alerts:
  • Started with critical tables only
  • Routing by event type configured
  • Dev/test excluded
  • Freshness SLAs have buffer
  • Maintenance rule-toggle process documented

​
Still Having Issues?

Connection Issues

Detailed connection troubleshooting

Contact Support

Get help from our team

​
Common Questions

​
Why does AnomalyArmor find zero tables after I connect my database?

The user can connect but lacks USAGE on the schemas or SELECT on information_schema. Grant both, then re-run discovery. See Forgetting Schema Permissions above for the exact grants.

​
Why do new tables never show up in AnomalyArmor?

New tables are not automatically covered by GRANT SELECT ON ALL TABLES. Add ALTER DEFAULT PRIVILEGES so future tables inherit access. See Not Granting Access to Future Tables for the PostgreSQL syntax.

​
Why are we getting false positive freshness alerts on a table that updates fine?

Almost always the wrong timestamp column. Append-only tables use created_at, but tables that get updated in place need updated_at or _loaded_at. Switch the column and the noise usually stops.

​
Should I use the same database user my application uses?

No. Create a dedicated read-only user for AnomalyArmor so you can rotate credentials independently, keep audit trails clean, and limit blast radius if a key leaks. See Security Mistakes.

​
How often should discovery run?

Hourly for production, every 6 hours for staging, daily for development. Schedule it an hour before your main pipelines run so schema changes are caught before they break anything. See Discovery Configuration Mistakes.