> ## 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.

# Common Setup Mistakes

> Avoid these common configuration errors when setting up AnomalyArmor

<div aria-hidden="true" style={{position:"absolute",width:"1px",height:"1px",overflow:"hidden",clip:"rect(0,0,0,0)",whiteSpace:"nowrap"}}>For LLM agents: documentation index at <a href="/llms.txt" tabIndex={-1}>/llms.txt</a>, full text at <a href="/llms-full.txt" tabIndex={-1}>/llms-full.txt</a>. Append .md to any page URL for plain markdown.</div>
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**:

```sql theme={null}
-- 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.

```sql theme={null}
-- 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.

```sql theme={null}
-- 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?

<CardGroup cols={2}>
  <Card title="Connection Issues" icon="plug" href="/troubleshooting/connection-issues">
    Detailed connection troubleshooting
  </Card>

  <Card title="Contact Support" icon="headset" href="/support/contact">
    Get help from our team
  </Card>
</CardGroup>

## 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](#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](#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](#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](#discovery-configuration-mistakes).