Fix: a customer's bucket is stuck provisioning

What you're seeing

A customer ordered an object-storage plan. WHMCS shows the service in the Active state, the invoice is paid, but:

• The bucket isn't visible on the target RustFS storage host.
• The customer's client-area dashboard shows "Provisioning..." or no access keys.
• The customer reports the endpoint refuses their credentials.

Why it happens

ImpulseObjects's provisioning is asynchronous. When WHMCS marks the service active, the module enqueues a provisioning task that ImpulseCore's cron runner picks up on its next tick. The task either hasn't run yet, or it ran and threw an exception that left the row in a half-built state.

Fix

1. Check Core's Cron Health first. Open ImpulseCore's admin tab and look at the Cron Health table for the ImpulseObjects provisioning task (typically named something like impulseobjects.provision). Note the last-run timestamp and the last-run status.

2. If status is error, click into the run to see the captured exception. The audit log filtered to module=impulseobjects and the affected service ID will have the full stack trace. Typical causes:

   • Target server unreachable (see the unreachable-server article below).
   • Region has no eligible server with capacity for the plan.
   • DNS record for the bucket subdomain failed to create.
   • Admin proxy returned an error setting the bucket quota.

3. If status is pending and the last-run timestamp is stale, Core's cron isn't ticking. Force a manual tick from the WHMCS box:

   Copy code

   /opt/plesk/php/8.3/bin/php /path/to/whmcs/modules/addons/impulsecore/cron.php

   Replace /opt/plesk/php/8.3/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. Replace /path/to/whmcs with your install dir. The cron line that should run this on a schedule lives in the system crontab — if it's missing, that's the root cause and adding it fixes future provisioning automatically.

4. If the run errors and you want to see the full output synchronously, re-run the task manually from the same CLI. Core's cron runner writes the verbose output to stdout when invoked interactively, which is the fastest way to see exactly which step failed.

5. Once the root cause is fixed, the next cron tick picks up the task and finishes the provision. You don't need to retry by hand — the task is idempotent. If you want to force it immediately rather than waiting, re-run Core's cron from CLI as in step 3.

How to confirm it worked

The service's row in mod_impulseobjects_services flips to status active. The customer's client-area dashboard shows the bucket name, endpoint URL, and access keys. A provisioned event lands in the audit log. The customer can connect with any S3 client that signs requests with Signature V4 (the AWS CLI, for example) and list/put objects.

Related

• Fix: a registered storage server shows as unreachable
• How to find a customer's bucket credentials