Common Setup Mistakes

Avoid these common configuration errors when setting up 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:

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:

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:

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