Fix: a customer's bucket is stuck provisioning

What you're seeing

A customer ordered an ImpulseDrive plan. WHMCS shows the service in the `Active` state, the invoice is paid, but:

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

Why it happens

ImpulseMinio'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 ImpulseMinio provisioning task (typically named something like impulseminio.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=impulseminio 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 from setBucketQuota.
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:

   /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_impulseminio_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 mc alias set or any S3 client and list/put objects.

Related

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