1. Identify the provider service or account ID, domain where relevant and the authorised customer relationship. Use the provider's private support channel.
2. Describe the impact precisely: which function fails, which users are affected and whether the issue is continuous or intermittent.
3. Record the first observed time, recent occurrences and timezone. Include a reproducible request or exact redacted error.
4. Summarise checks already completed, including the result. Distinguish confirmed observations from possible explanations.
5. List recent relevant changes and any recovery attempt. If an API request timed out, state whether the remote resource already exists or the provider transaction completed.
6. Include request IDs, queue IDs or message IDs that the provider can trace. Remove credentials, access tokens and unrelated customer content from attachments.
7. Ask for a specific next action, such as checking a failed provisioning request, confirming a resource limit or restoring a documented backup point.

Link the provider case to your internal customer ticket and assign an owner. Record provider findings, the next promised update and any action awaiting approval. Keep customer communication clear even when the provider has not yet identified a cause.

Before following a suggested destructive command, verify its target and recovery consequences. Confirm the change is within the customer's approved scope and record the result afterwards.

• Keep a useful timeline during a hosting incident
• Define support responsibilities between a reseller and provider
• Record and review changes to customer hosting services
• Use HostBill logs to investigate an operational failure

• HostBill task queue log
• HostBill system log
• WHMCS server troubleshooting
• WHMCS logs