Common Setup Mistakes - AnomalyArmor

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.

Database	Correct Port	Common Mistake
PostgreSQL	5432	3306 (MySQL)
ClickHouse HTTPS	8443	9000 (native)
ClickHouse HTTP	8123	9000 (native)
Databricks	443	N/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:

Go to Settings → Security to find AnomalyArmor IPs
Add them to your security group/firewall rules
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:

Start with 5-10 critical production tables
Alert only on breaking changes (column removed, table removed)
Exclude dev/test environments
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:

Go to Alerts → Rules
Toggle OFF relevant rules
Set a reminder to re-enable
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:

Environment	Discovery Frequency
Production	Hourly
Staging	Every 6 hours
Development	Daily

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 Type	Right 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:

Longer SLA (72 hours for daily data)
Disable rules on Friday, re-enable Monday
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: 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.

​Database Connection Mistakes

​Wrong Port Number

​SSL Not Enabled

​Forgot to Allowlist IPs

​Using Wrong Endpoint (AWS)

​Permission Mistakes

​Insufficient Database Permissions

​Forgetting Schema Permissions

​Not Granting Access to Future Tables

​Alert Configuration Mistakes

​Alerting on Everything

​Same Destination for All Severities

​Too-Tight Freshness SLAs

​Not Disabling Rules During Maintenance

​Discovery Configuration Mistakes

​Discovery Too Infrequent

​Not Scheduling Before Pipeline Runs

​Including Unnecessary Schemas

​Freshness Monitoring Mistakes

​Wrong Timestamp Column

​Not Handling Weekends

​Security Mistakes

​Using Production Application Credentials

​Not Using SSL

​Checklist: Before Going Live

​Still Having Issues?