Investigate an AI problem in layers: service access, product tools, saved provider configuration, usage limits and the operation itself. This avoids charging repeated requests against a condition that needs a configuration change.
IN THIS ARTICLE
01 When the Engineer is missing
- Confirm the service is active and belongs to the client account the user is currently accessing.
- Check the user's WHMCS product-management permissions and any Hosting Suite access rules.
- Verify Enable customer AI and the relevant WordPress Engineer or Hosting Engineer switch.
- For an application product, inspect its customer tools and server capabilities. The Hosting Engineer is filtered by the application plan.
- Check whether account writes are paused. This affects WordPress AI operations; the Hosting Engineer can still have inspection uses where permitted.
02 When a request fails before useful work
Open AI engineers & credits and use Test the saved AI. Check the exact model identifier, API key status and provider-account entitlement. If the provider reports rate limits, unavailable capacity or a billing condition, resolve that with the provider before retrying from many services.
Review the service's free allowance, purchased balance and the module's monthly usage cap. A paid balance does not override every usage limit. Compare the UTC date when a customer believes a daily allowance should already have reset.
What should I do when AI work stops partway through?
An Engineer request has execution and tool-round limits. A complicated task may require smaller steps, and a response stopping does not prove that no earlier action ran. Inspect the action history and the affected resource before sending the same instruction again.
For the website builder, use Continue building when appropriate instead of automatically starting over. The full build can already have published pages and changed the active theme. Review those results first. Start again and the option to replace previously generated pages have different consequences.
03 Check credits and recover safely
Paid requests reserve an estimate, settle measured usage and return unused reservations. Failed reserved requests follow the refund handling in that workflow. Compare the request, invoice and service records before making manual adjustments.
If a change is wrong, stop further changes. Use Undo only for an eligible tracked action, or recover from the backup that covers the affected data. Do not assume a failed final response means a shell command, SQL operation or plugin action was undone.
Escalate with the module version, service, provider, model, timestamp and sanitised error text. Exclude API keys, private keys, passwords and customer content that is unnecessary to reproduce the problem.