Fix: a customer's Postgres instance is stuck pending

WHMCS shows an ImpulseDB Postgres service as active, but the instance never appears on the admin tab and the customer can't connect.

Last updated 20 days ago

Fix: a customer's Postgres instance is stuck pending

What you're seeing

A customer ordered an ImpulseDB Postgres plan, payment posted, and WHMCS flipped the service to Active. But the customer can't connect, no instance shows up on the Servers tab (for shared) or Dedicated Servers tab (for dedicated), and the client-area service page is missing the connection details card.

Why it happens

ImpulseDB Postgres provisions asynchronously. On a new order, the addon queues a provisioning task and waits for the next cron tick. Two things can stall the task:

  • The provisioning cron isn't running at all — the cron entry was never installed, or the PHP binary path is wrong.
  • The cron ran but errored partway through — SSH key mismatch, DNS API token missing a permission, VPS provider rejected the create call, or the bootstrap script on the new VPS itself failed.

Fix

  1. Check the provisioning cron heartbeat. Open Tools > Diagnostics > Provisioning Cron Heartbeat. If the timestamp is missing or older than a few minutes, the cron isn't firing. Confirm the crontab line is installed on the WHMCS box: 
    */2 * * * * /usr/bin/php /path/to/whmcs/crons/impulsepostgres_provision.php
    Replace /usr/bin/php with your PHP CLI binary. On Plesk: /opt/plesk/php/8.3/bin/php. On cPanel: /opt/cpanel/ea-php83/root/usr/bin/php. On a vanilla LAMP install: /usr/bin/php or whatever which php returns.
  2. Filter the audit log to this service. Under Tools > Audit Log, filter to module=impulsedb-postgres and the affected service_id. The most recent rows show exactly where the task stopped — a provider.create_failed, dns.update_failed, or bootstrap.failed event names the failing step.
  3. For dedicated plans stuck in provisioning, the VPS spawned but its cloud-init bootstrap didn't finish. Open the row on the Dedicated Servers tab and click View Bootstrap Log to pull /var/log/pg-bootstrap.log from the VPS over SSH. Common failures:
    • SSH key mismatch — the public key in cloud-init doesn't match the private key on the WHMCS box.
    • DNS API token missing Zone:Read for the Let's Encrypt DNS-01 challenge.
    • The provider's edge DNS hasn't propagated yet. The bootstrap script retries for 5 minutes before falling back to a self-signed cert.
  4. For dedicated plans flipped to provision_failed, the provisioning cron exceeded its timeout (default 10 minutes). The row gets Retry and Destroy buttons. Retry re-runs with the same config; Destroy abandons the VPS and cleans up the DNS record.
  5. For shared plans stuck pending, the failure is almost always on the admin SQL step. Check the row for the target shared server and confirm it's reachable. If the shared host itself is unreachable, see the related article below.

How to confirm it worked

The customer's row appears on the appropriate tab with a green online badge within one cron tick after the underlying issue is fixed. The audit log records a provision.completed event. The client-area service page now shows the connection details card with hostname, database name, and password reveal.

Related