Fix: a registered Postgres server shows as unreachable

A Postgres host registered with ImpulseDB Postgres is showing as unreachable on the Servers tab, and provisioning tasks targeting it stall or fail.

Last updated 20 days ago

Fix: a registered Postgres server shows as unreachable

What you're seeing

A row on the ImpulseDB Postgres Servers tab is showing an amber or red status badge. Provisioning tasks that target this server hang in the cron runner or fail outright, and new customer orders routed to it stay in provisioning state. The audit log under Tools > Audit Log filtered to module=impulsedb-postgres shows connection-refused, authentication-failed, or TLS-handshake exceptions for the host.

Why it happens

The WHMCS box talks to each Postgres host over two channels:

  • Postgres on TCP 5432 for admin SQL (creating roles, databases, applying quotas) using the admin role's credentials.
  • SSH (TCP 22, or whatever you configured) for host-level operations like backups, WAL-G install, and the Security pipeline collector.

If either channel is broken, the row is reported unreachable. The usual culprits are firewall rules (especially missing IPv6 entries), a pg_hba.conf that doesn't allow the WHMCS IP, rotated admin credentials, or a renewed TLS cert that the WHMCS box doesn't trust yet.

Fix

  1. Confirm the host is reachable at the IP level. From the WHMCS box: 
    ping -c 3 shared-us-1.example.com ping6 -c 3 shared-us-1.example.com
  2. Test the Postgres endpoint directly. This isolates an auth problem from a connectivity problem: 
    psql -h shared-us-1.example.com -p 5432 -U <admin_user> -d postgres
    Use the admin credentials stored on the server row. A password prompt that hangs means a firewall block. FATAL: no pg_hba.conf entry means the WHMCS host isn't allowed yet. FATAL: password authentication failed means the credentials drifted.
  3. Confirm UFW covers both address families on the Postgres host. SSH in and run: 
    ufw status numbered
    Every WHMCS IP needs a rule for ports 5432 and 22 in both tcp and tcp6. An IPv4-only rule reads fine but blocks any WHMCS install that resolves to IPv6 first.
  4. Check pg_hba.conf for the client allowlist. Postgres listens on 5432 with ingress restricted to client-managed allow-lists. The WHMCS IP needs an entry here too: 
    sudo grep "<whmcs_ip>" /etc/postgresql/16/main/pg_hba.conf
    If it's missing, add a host all all <whmcs_ip>/32 scram-sha-256 line and pg_ctl reload.
  5. Look at the verbatim error in the audit log. Under Tools > Audit Log, filter to the affected service_id or server_id. The exception text usually points straight at the failing step — admin proxy auth, SSH key mismatch, or TLS trust.

How to confirm it worked

The server row's status badge flips back to green online on the next provisioning cron tick (within 2 minutes). The audit log stops appending new exceptions for this host. Any provisioning task that was stuck retries on its own.

Related