Practical guide

Write a support request that can be acted on

Last materially reviewed 2026-09-21

Quick answerProvide timestamps, affected paths and recent changes without exposing secrets or customer records.
What to know

Lead with the exact observable problem

State the affected function, canonical path and approximate time, followed by what you expected and what actually happened. A concise factual brief is more useful than a long conclusion that the host is broken. Include whether the issue affects one application or several where that is known. Do not expose passwords, API keys, customer records or sensitive request parameters in screenshots or copied logs used to explain the incident.

What to know

Preserve the recent change history

Record the last accepted version and relevant changes near the incident. Keep original operation identifiers and receipts when a deployment or restore may be involved. A fictional team should not erase a failed attempt from its notes just because a later page load worked. The history helps distinguish a confirmed failure, delayed completion and an unknown outcome, each of which can require a different safe next step.

What to know

Explain completed diagnostic checks and tests

List bounded observations and their results, not a vague statement that everything was tried. Note which checks were read-only and which authorized changes were made. If an operation could have completed after a timeout, say so explicitly and avoid a blind resend. The recipient should be able to identify a useful next diagnostic step without repeating expensive work or assuming that an acknowledgement proves the application is healthy.

What to know

Ask for a capability-specific next action

Cloudways support has a documented scope and exclusions. Frame the request around the infrastructure or platform evidence you need, while keeping application responsibilities with the appropriate operator. If custom-code behavior is outside the support scope, identify the missing application investigation instead of promising the client that the host will fix everything. A good incident brief reduces repeated explanation and keeps the recovery decision tied to evidence and authority.

Continue when useful

Next: What Cloudways support covers—and what stays with you

Managed hosting is not an unlimited promise to debug custom code or operate your business.

Open What Cloudways support covers—and what stays with you →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Cloudways support tiers and explicit exclusions — Merchant documentation · cloudways.com · Merchant-controlled · checked 2026-09-21
  2. Cloudways 502 diagnosis — Merchant documentation · support.cloudways.com · Merchant-controlled · checked 2026-09-21