I appreciate that this may not be a trivial production change, and I am not pretending to know the internal complexity of Cloudways’ scaling workflow, provider integrations, queue handling, or front-end state management. But from the outside, as a customer, the current experience is not just slightly imperfect. It sets an expectation that appears to be materially untrue.

The issue is the message:

“Your scaled server will be ready in 5 minutes”

That is not presented as a loose estimate, a range, or a general reassurance. It is phrased as a direct statement of what is going to happen. If the same interface then remains in “Scaling Server” status for 10, 15, 20 minutes or longer, the message stops being helpful and starts to feel like a fabrication.

I do not mean fabrication in the sense that someone intentionally wrote a dishonest message. I mean it in the customer experience sense: the product is telling me something specific that the support bot then immediately contradicts.

The UI says: ready in 5 minutes.

The bot says: actually it can take 1–15 minutes, sometimes 15–30 minutes, and only after 1 hour should I treat it as a support issue.

Those two things cannot both be good customer communication.

If the operational reality is that scaling can normally take up to 15 minutes, sometimes 30 minutes, and occasionally long enough that support does not recommend escalation until 60 minutes, then the UI should not be telling customers “ready in 5 minutes” as if that is a reliable promise.

That matters because this is not a cosmetic workflow. Server scaling is a moment where the customer is already alert. They may be scaling because traffic has increased, performance is under pressure, a site is live, a community is active, or a client is waiting. This is precisely the kind of action where clear, truthful status messaging matters most.

The current message creates a bad chain of events:

First, the UI sets a five-minute expectation.

Then the customer waits beyond five minutes.

Then the customer starts to worry that the operation may have stalled.

Then the customer contacts support.

Then the bot says the actual window is much longer.

Then the customer asks whether the specific server can be checked.

Then the bot says it cannot check the specific server.

Then the bot repeatedly reassures the customer based only on generic timing guidance.

That is not a great experience. It makes the customer feel trapped between an overconfident UI message and an underpowered support bot.

The part that is especially frustrating is that the bot keeps saying, in effect, “this is normal,” while also saying it cannot actually check whether this specific scaling operation is normal. That distinction matters.

A more honest answer would be:

“I cannot directly inspect the backend status of this specific scaling operation from here. Based on typical timing, it may still be within the expected range, but I understand why the 5-minute UI message is causing concern.”

That would be much better than repeatedly telling the customer not to worry while also admitting there is no actual visibility into the individual job.

From a UX perspective, the minimum improvement would be to stop using a fixed “ready in 5 minutes” message unless Cloudways is genuinely confident that the overwhelming majority of scaling operations complete within that time.

If the real answer is more nuanced, the UI should be more nuanced.

For example:

“Scaling your server. This usually takes 5–15 minutes.”

That alone would be materially better.

A better version would be:

“Scaling your server. This usually takes 5–15 minutes, but may take up to 30 minutes depending on provider availability, disk size, and current server state.”

An even better version would be time-aware messaging:

0–5 minutes:
“Scaling your server. This usually takes 5–15 minutes.”

5–15 minutes:
“Still scaling. This is within the normal range.”

15–30 minutes:
“Scaling is taking longer than average, but can still be normal depending on provider availability and server state.”

30–45 minutes:
“This is taking longer than expected. You may continue waiting or contact support for a check.”

45–60 minutes:
“This is outside the usual window. Please contact support so we can investigate.”

60+ minutes:
“Scaling appears to be taking unusually long. We recommend escalating to support.”

That does not require promising exact progress if the system cannot measure exact progress. It only requires the product to stop presenting one fixed number as if it is reliable when support knows it may not be.

If dynamic progress is hard to implement, even a static message would be better:

“Scaling times vary. Most servers are ready within 5–15 minutes. Some may take up to 30 minutes or longer depending on provider conditions and server data. If scaling continues beyond 60 minutes, contact support.”

That is not perfect, but it is much more honest than “ready in 5 minutes.”

The support bot also needs improvement. Once a customer says, “the UI says 5 minutes but it has been more than 15,” the bot should not just repeat the same generic message. It should recognise that the customer is reporting a mismatch between product messaging and operational reality.

A better bot response would be:

“You are right to question that. The 5-minute message is only an estimate, and it can be misleading when scaling takes longer. I’ll treat that as product feedback. Operationally, the usual range is closer to 5–15 minutes, with some cases taking 15–30 minutes. Since I cannot directly verify this specific job from here, I can either help you monitor it or connect you with support if you want someone to check the backend status.”

That response does three important things:

It acknowledges the customer’s point.
It explains the real operational range.
It gives the customer an escalation path.

The current bot does not really do that. It asks me to describe what I want changed, as though the problem is unclear. The problem is already clear: the UI is giving a precise time estimate that does not match the actual support guidance.

From a customer point of view, I should not have to design the exact replacement copy for Cloudways. The feedback is that the existing copy is misleading. Product, UX, and support teams can decide the implementation. My suggestion is simply that Cloudways should use a realistic range, time-aware messaging, and an escalation threshold rather than continuing to show a fantasy five-minute promise.

To be clear, I am not saying scaling should always finish in five minutes. Infrastructure operations vary. Provider-side delays happen. Hypervisor availability, disk operations, snapshots, resizing, package changes, queues, and platform orchestration can all affect timing. Customers can understand that.

What customers struggle with is being told one thing by the UI and another thing by support.

If support says the realistic window is up to 30 minutes in rare cases, and support does not recommend escalation until 1 hour, then the UI should reflect that reality. Otherwise, Cloudways is effectively manufacturing avoidable concern and then using support automation to talk the customer down from an expectation Cloudways itself created.

There is also a trust issue here. Once a customer sees that the “5 minutes” message is not reliable, they start questioning the rest of the status information. Is the scaling actually progressing? Is the process queued? Has it stalled? Is the provider waiting? Is Cloudways waiting? Is there a failed backend task? The interface does not answer those questions, and the bot cannot check them.

A more useful status model could include broad stages, even if exact percentages are not available:

“Preparing scaling operation”
“Requesting resources from provider”
“Resizing server”
“Finalising configuration”
“Running checks”
“Scaling complete”

Even if Cloudways cannot expose every backend detail, showing a stage is more reassuring than showing the same “ready in 5 minutes” message long after five minutes has passed.

If that is too much development work, then the simplest realistic improvement is copy-only:

Current:
“Your scaled server will be ready in 5 minutes”

Suggested:
“Scaling is in progress. Most scaling operations complete within 5–15 minutes, but some may take longer. If this continues beyond 60 minutes, contact support.”

Better:
“Scaling is in progress. Typical time: 5–15 minutes. May take up to 30 minutes depending on provider availability and server state. We recommend contacting support if it exceeds 60 minutes.”

Best:
A dynamic message that changes as elapsed time increases and offers escalation once the displayed estimate has been exceeded.

The important principle is this:

Do not give customers a precise promise unless the system can stand behind it.

If Cloudways cannot confidently say “ready in 5 minutes,” then the product should not say it.

A less precise but accurate message is better UX than a precise but misleading one. It reduces anxiety, reduces unnecessary support contacts, and preserves trust during a sensitive infrastructure operation.

So yes, my feedback is:

Please log this as product/UX feedback. The current “ready in 5 minutes” scaling message is misleading when the real operational guidance is 5–15 minutes, sometimes 15–30 minutes, and potentially up to 60 minutes before escalation. It would be much better to show a realistic range, update the message as time passes, and allow the bot to escalate or at least acknowledge the mismatch once the UI estimate has been exceeded.

I understand that my suggested solution may not be exactly what makes sense for production, but the current approach needs improvement. Right now, from the customer side, it feels like the product is displaying a confident fantasy rather than a reliable operational status.