Separate a pending billing-service activation from a cluster request that DigitalOcean is still processing. This avoids repeating a create action while a real cluster may already exist.

Identify where progress stopped

1. Check whether the billing service has reached its intended activation step. Review paid-pending-services automation and any manual-activation hold on the package.
2. Confirm that the service uses PD DigitalOcean Kubernetes, the intended saved provider account and the expected region, node plan, node count and version.
3. Open PD Modules → DigitalOcean Kubernetes → Clients & Clusters and find the tracked service.
4. Review Activity and the latest redacted result. Note whether the issue was reported before a provider resource was created, during cluster creation, or after it began provisioning.

A service marked active, a connection check or a successful initial create response does not establish that the Kubernetes cluster reached Running. The module’s background process must observe the provider result and update the saved endpoint/state.

Resolve the reported cause

For missing credentials or authentication errors, review the intended provider account and token status. For a permission error, ask the DigitalOcean administrator to review the named resource scope. The connection test only reads account information.

For a missing node plan or a plan/region refusal, review the offering and actual order choices. Not every standalone Droplet size is supported for Kubernetes or available in every region. Use the module’s Kubernetes choices and the exact provider error rather than repeatedly selecting a larger plan at random.

For Provisioning or Applying changes, check that the normal automation cron is running and inspect the provider’s current outcome through your authorised administration process. A provider read failure can leave a previous state visible. Degraded or Failed needs investigation; it does not prove no resource exists or that billing stopped.

Reconcile before retrying

If the module says it is checking for an existing cluster, allow that check to resolve. Do not create a separate service or order to work around an uncertain result. Reconcile the existing service and provider cluster first.

If the cluster reaches Running but clients cannot download kubeconfig, check Client: Kubeconfig download and the separate download permission. If the node view is empty, investigate the provider read; if nodes are present but an application fails, investigate the workload separately from provisioning.

Do not send API tokens, kubeconfig, workload secrets or a full customer record. Preserve the original service record while checking the actual cluster state.

See the PD DigitalOcean Kubernetes Blesta guide for related setup, or explore PD DigitalOcean Kubernetes.