Connection Issues

Troubleshoot database connectivity problems

This guide helps you diagnose and fix common database connection problems. If you’re having trouble connecting AnomalyArmor to your database, start here.

Quick Diagnosis

Use this decision tree to identify your issue:

Error Message	Likely Cause	Jump To
”Connection refused”	Network/firewall issue	Connection refused
”Authentication failed”	Credentials issue	Authentication failed
”SSL required”	SSL configuration issue	SSL required
”Permission denied”	Database permissions issue	Permission denied
”Timeout”	Network latency issue	Timeout

Connection Test Failures

”Connection refused”

What it means: AnomalyArmor can’t reach your database at all.

What you’ll see: When you click “Test Connection” in the Add Connection form, you’ll see a red destructive toast notification with:

• Title: “Error”
• Message: “Connection refused - Could not connect to database at mydb.us-east-1.rds.amazonaws.com:5432”
• Details: A list of possible causes:
  • Firewall/security group blocking connection
  • Incorrect hostname or port
  • Database not running

The toast appears in the top-right corner of the screen and includes action buttons to retry or edit the connection settings.

Common causes:

1. Firewall/security group blocking the connection
2. Wrong hostname or port
3. Database not running or not accepting connections

Troubleshooting steps:

1. Verify hostname and port

Double-check the hostname. Typos are common:

Common mistakes:
[X] mydb.rds.amazonaws.com (missing region)
[OK] mydb.us-east-1.rds.amazonaws.com

[X] Port 3306 (MySQL default)
[OK] Port 5432 (PostgreSQL default)

2. Check firewall/security group

AnomalyArmor needs inbound access on your database port.

AWS RDS/Aurora:

1. Go to RDS Console → Your instance → Security Groups
2. Add inbound rule:
   • Type: PostgreSQL (or your DB type)
   • Port: 5432 (or your port)
   • Source: AnomalyArmor IPs (see Settings → Security)

Google Cloud SQL:

1. Go to SQL Console → Your instance → Connections
2. Under “Authorized Networks”, add AnomalyArmor IPs

Self-hosted:

# Allow AnomalyArmor IPs
iptables -A INPUT -p tcp --dport 5432 -s 34.xxx.xxx.xxx -j ACCEPT

3. Verify database is running

Can you connect from another location?

# Test from your local machine
nc -zv your-host.rds.amazonaws.com 5432

# Expected output (success):
Connection to your-host.rds.amazonaws.com port 5432 [tcp/postgresql] succeeded!

# If it fails, the issue is likely firewall-related

4. Check for VPC/private network issues

If your database is in a private subnet:

• It may not be accessible from the internet
• You may need VPC peering or PrivateLink (Enterprise)
• Contact us about private connectivity options

”Authentication failed”

What it means: AnomalyArmor reached your database but the credentials were rejected.

What you’ll see: A red error notification appears with a message like:

Connection failed

Authentication failed - FATAL: password authentication failed for user ‘anomalyarmor’

Possible causes:

• Incorrect username or password
• User doesn’t exist in the database
• User lacks CONNECT permission

Common causes:

1. Wrong username or password
2. User doesn’t exist
3. User doesn’t have permission to connect

Troubleshooting steps:

1. Verify credentials

Copy-paste to avoid typos:

• Copy the username exactly as it appears in your database
• Copy the password (watch for leading/trailing spaces)
• Check for special characters that may need escaping

2. Confirm user exists

Connect to your database and check:

-- PostgreSQL
SELECT usename FROM pg_user WHERE usename = 'anomalyarmor';

-- ClickHouse
SELECT name FROM system.users WHERE name = 'anomalyarmor';

3. Reset the password

If unsure, reset the password:

-- PostgreSQL
ALTER USER anomalyarmor WITH PASSWORD 'new-secure-password';

-- ClickHouse
ALTER USER anomalyarmor IDENTIFIED BY 'new-secure-password';

Then update the password in AnomalyArmor.

4. Check pg_hba.conf (PostgreSQL)

For self-hosted PostgreSQL, check pg_hba.conf allows the connection:

# Add entry for AnomalyArmor
hostssl all anomalyarmor 34.xxx.xxx.xxx/32 scram-sha-256

Reload PostgreSQL after changes:

sudo systemctl reload postgresql

“SSL required” / “SSL connection error”

What it means: The database requires SSL but the connection isn’t using it (or vice versa).

What you’ll see: A red error notification appears with a message like:

Connection failed

SSL connection required - server requires SSL connection

Solution: Set SSL Mode to ‘require’ in your connection settings and try again.

Troubleshooting steps:

1. Enable SSL in AnomalyArmor

Edit your connection:

1. Go to Data Sources → Your connection → Settings
2. Set SSL Mode to require
3. Save and test

2. Try different SSL modes

Mode	Description
disable	No SSL (not recommended)
require	SSL required, no certificate verification
verify-ca	Verify server certificate
verify-full	Verify certificate and hostname

Start with require for most cloud databases.

3. Check cloud provider requirements

• AWS RDS: Requires SSL by default, use require
• Aurora: Requires SSL, use require
• Supabase: Requires SSL, use require
• Google Cloud SQL: Requires SSL, use require
• ClickHouse Cloud: Always HTTPS on port 8443

”Timeout” / “Connection timed out”

What it means: The connection attempt took too long.

Common causes:

1. Network latency
2. Firewall silently dropping packets
3. Database under heavy load

Troubleshooting steps:

1. Check network path

Test connectivity from your own machine:

# Test if port is reachable
nc -zv -w 10 your-host.com 5432

# Test latency
ping your-host.com

2. Check security groups

If the security group doesn’t have an explicit allow rule, packets may be silently dropped (causing timeout instead of refused).

3. Try during off-peak hours

If the database is under heavy load, connections may time out.

”Permission denied” / “Access denied”

What it means: Connection succeeded but the user can’t access the required data.

Troubleshooting steps:

1. Grant CONNECT permission

-- PostgreSQL
GRANT CONNECT ON DATABASE your_database TO anomalyarmor;

2. Grant schema access

-- PostgreSQL
GRANT USAGE ON SCHEMA public TO anomalyarmor;
GRANT USAGE ON SCHEMA analytics TO anomalyarmor;

3. Grant table access

-- PostgreSQL
GRANT SELECT ON ALL TABLES IN SCHEMA public TO anomalyarmor;

-- For future tables
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO anomalyarmor;

4. Verify with test query

Connect as the anomalyarmor user and run:

SELECT table_name FROM information_schema.tables LIMIT 5;

If this fails, you need more permissions.

Discovery Failures

If connection tests pass but discovery fails:

“No tables found”

Causes:

• User can connect but can’t see tables
• Schema filter excluding all schemas
• Connected to wrong database

Solutions:

1. Check schema filter settings
2. Verify user has SELECT on information_schema
3. Confirm database name is correct

”Discovery timeout”

Causes:

• Very large database (10,000+ tables)
• Slow network
• Database under load

Solutions:

1. Exclude unnecessary schemas
2. Run during off-peak hours
3. Consider using a read replica

Provider-Specific Issues

AWS RDS

Common issues:

• Security group not allowing AnomalyArmor IPs
• Using private subnet without public access
• Wrong endpoint (cluster vs instance)

Solutions:

1. Add AnomalyArmor IPs to security group
2. Enable “Publicly accessible” or use VPC peering
3. Use the correct endpoint for your use case

Databricks

Common issues:

• Invalid or expired access token
• Wrong HTTP path
• SQL warehouse not running

Solutions:

1. Generate a new access token
2. Copy HTTP path from SQL Warehouse settings
3. Ensure warehouse is running or use serverless

ClickHouse

Common issues:

• Using native port instead of HTTP port
• HTTP interface disabled
• IP not in user’s allowed hosts

Solutions:

1. Use port 8443 (HTTPS) or 8123 (HTTP)
2. Enable HTTP interface in config.xml
3. Add IPs to user’s HOST restriction

Still Stuck?

If you’ve tried everything above and still can’t connect:

1. Collect diagnostic info:

   • Error message (exact text)
   • Database type and version
   • Cloud provider (if applicable)
   • Network setup (public/private subnet)

2. Contact support:

   • Email: [e-mail]
   • Include the diagnostic info above
   • We can help troubleshoot complex network setups

Contact Support

Get help from our team