"It's not working, please help" and a ticket with the exact error, the server ID, and a list of what you already tried land in the same queue - and get very different answers. We cover where to open a ticket in my.weasel.cloud, what separates Sale support from Tech support, and why those details matter more when there's no web console to fall back on.
SSH suddenly stops letting you in, the client area shows a service status you don't understand, or the question isn't about the server at all, it's about a charge - and neither the knowledge base nor a search turns up your exact case. That leaves a support ticket. One thing about WeaselCloud is easy to forget here: the client area has no web console and no reboot button, so an agent can't just open your server and look at what's happening the way they could in a panel with a built-in console. They see exactly what you wrote and nothing more. The gap between a ticket that gets closed in one reply and one that turns into a three-day back-and-forth usually isn't luck or queue position - it's the first message.
Short version. In
my.weasel.cloud, open a ticket under Support -> Open Ticket. Pick a department: Tech support for anything happening on the server itself (access, network, errors), Sale support for plans, billing, and pre-purchase questions. In the message, name the server right away (service ID or hostname, something likeweasel-de-379636a9ac4711878b), paste the exact error text as your terminal shows it, list what you already tried, and if access is gone entirely, spell out exactly what happens when you attempt to connect. Since the panel gives support no way to look over your shoulder, those details in the first message decide whether you get one reply or five.
Where to open a ticket in the client area
In my.weasel.cloud, a ticket opens under Support, via the Open Ticket button. That same path is also the only way to handle several things that have no dedicated form of their own in the panel: ordering an extra PTR record for a server, for instance, goes through this exact ticket flow rather than a separate menu item (more on that in PTR records and extra IPv4 addresses). Access recovery works the same way. Lock yourself out of SSH through a ufw mistake or a bad config edit, and the only route back in is that same ticket, because there's no reboot button or web console to poke around in on your own.
Worth keeping in mind from the start: here, a ticket isn't just one option among several for getting help, it's frequently the only one. That makes what you write in your first message worth more than it would in a panel that ships with a real console, where an engineer can just go look for themselves.
Sale support or Tech support: picking a department
The ticket form asks you to pick a department before anything else. Getting it right usually shaves a day off the reply; getting it wrong doesn't kill the ticket, it typically just means one extra hop between queues.
Department | When to pick it | Example questions |
|---|---|---|
Tech support | anything happening on the server itself or on the network in front of it | SSH not responding, an error during OS install, odd network latency, a PTR record request |
Sale support | anything involving money, plans, or pre-purchase decisions | which plan fits a given workload, a billing or charge question, upgrading to a bigger disk, a promo code that didn't apply |
When in doubt, pick based on who can actually act on it: a technical engineer isn't the one adjusting a charge, and a sales rep isn't going to fix your SSH config. Some screens may show a third option not seen during the last panel check - if you spot one, pick whichever fits your question best.
What to include so the first reply is a fix, not a question
Your first message decides whether the answer is a solution or a follow-up question. That matters more here than on most panels, because WeaselCloud support has no console to check things themselves - your ticket text is all the information they have. Include:
- which server this is about - the service ID from your client area, or the hostname, something like
weasel-de-379636a9ac4711878b. Skip this and the first reply is almost certainly a request to clarify which server you mean; - the exact error, pasted, not paraphrased - "it doesn't connect" and
ssh: connect to host 185.x.x.x port 22: Connection refusedare two different problems for an engineer, and the second one already carries half the diagnosis; - what you did right before it broke - changed ufw rules, edited
sshd_config, ran a system update, upgraded the plan, or nothing at all and it just stopped working; - what you already tried yourself - connecting from a different IP or network, a different SSH client, checking whether the server even answers a ping;
- for access problems specifically, the IP you're connecting from and exactly what happens - hangs on connect, drops immediately, or shows a specific error. Since support can't open a web console and watch the server's screen live the way some other panels allow, this is the closest substitute you can give them. A good chunk of "I can't get into my server" tickets would get solved in one reply instead of a back-and-forth if this detail were there from the start.
A bad ticket and a good ticket, same underlying problem
The difference is easiest to see on one specific case - SSH access disappearing right after enabling ufw.
Bad ticket | Good ticket | |
|---|---|---|
Subject | "Server isn't working" | "SSH unreachable right after ufw enable, server weasel-de-379636a9ac4711878b" |
Message | "Can't ping my server, please help, this is urgent" | "Ran |
Department | not picked, or picked at random | Tech support |
What the engineer is missing | which server, what actually happened, what's been checked already - without a console, an agent has to ask for all of this in a separate message, losing a round-trip | nothing - everything needed for a diagnosis is already in the first message |
The second ticket usually gets fixed in one reply - most likely the engineer either asks you to wait for a fix to take effect or offers a temporary access route through another channel, because they already have both the cause and a full picture of what you've ruled out.
What not to put in a ticket
Avoid pasting passwords or private SSH keys into a ticket unless there's no way around it - ticket threads stick around longer than you'll remember and often get read by more than one person on the support side. Here's the honest part: WeaselCloud's own VPS root password already sits in plain text on the "Hosting Information" tab of the client area, so mentioning it in a ticket doesn't introduce a fundamentally new risk that wasn't already there. But support almost never needs the password itself to diagnose anything - the exact error and what you've already checked are far more useful than the secret. If a case genuinely needs temporary access, for example to check a web server config, create a separate limited-privilege user for it and remove that user once the question is closed.
What to expect after you send it
WeaselCloud runs on WHMCS, a common billing platform among hosting providers, and the usual behavior there is an email notification every time support replies to a ticket, so you don't need to keep a tab open and refresh it. There's no publicly stated response-time promise or SLA on weasel.cloud - the FAQ block on the homepage answers questions about payment methods, the trial period, and setup time, not support speed. Rather than guess based on someone else's experience, treat the confirmation email and the ticket's status in your client area as your actual signal - a status change means someone has already looked at it.
When a ticket isn't the right move - check the knowledge base first
A ticket puts a real person on the other end, not an instant answer, so it's worth checking first whether your exact case is already covered somewhere. If SSH stopped working after touching ufw or editing sshd_config on a fresh server, the full sequence meant to prevent that, and what to do if it already happened, is covered in Securing a fresh VPS: the first 10 minutes. If the problem is a forgotten or wrong password rather than access itself, see changing a password in Ubuntu. A ticket is still the right call when your case doesn't fit any guide, the server behaves differently than documented, or the question isn't technical at all - a plan or a charge, for instance.
FAQ
Where do I open a ticket in the WeaselCloud client area
In my.weasel.cloud, under Support, via the Open Ticket button. The same path also covers requests that have no dedicated form of their own in the panel, such as a PTR record or an extra IPv4 address.
Which department should I pick - Sale support or Tech support
Tech support if the problem is on the server itself: access, network, an error during setup or operation. Sale support if it's about money, a plan, or something before you buy: invoices, an upgrade, a promo code, choosing a configuration. Picking the wrong one doesn't kill the ticket, it usually just adds a day for the reroute.
What should I write in a ticket to get it fixed fast
The server's ID or hostname, the exact error text as your terminal shows it, what you did right before it broke, and what you've already tried. For access problems, add the IP you're connecting from and exactly what happens - hangs, drops, or a specific error message. WeaselCloud has no web console, so support is working entirely from your description.
How fast does WeaselCloud support reply
There's no publicly stated response time or SLA on the site. WHMCS, which powers the client area, typically sends an email every time a ticket gets a reply - use that, and the ticket's status in your account, rather than a number from someone else's experience.
Is it safe to put a password in a support ticket
Better to avoid it, though the VPS root password in WeaselCloud already sits in plain text in the client area, so mentioning it in a ticket doesn't add a meaningfully new risk. That said, diagnosis almost never actually requires the password - the exact error and what you've already checked matter far more. If temporary access is genuinely needed, create a separate account for it and remove it once the issue is closed.
Key takeaways
- Tickets open in
my.weasel.cloudunder Support, via Open Ticket - the same path also covers requests with no dedicated form, like a PTR record. - Tech support handles anything on the server or its access; Sale support handles plans, billing, and pre-purchase questions.
- WeaselCloud has no web console and no reboot button, so support works entirely from what you write - details in the first message stand in for a live look at the screen.
- Name the server by ID or hostname, paste the exact error, and say what you did before it broke and what you already tried - that alone removes most of the back-and-forth.
- For access problems, add the connecting IP and exactly what happens - hangs, drops, or a specific error.
- Skip passwords and keys where you can, though the VPS root password already sits in plain text in the panel, so this isn't a new risk, just an unnecessary one.
- WeaselCloud publishes no SLA - go by the confirmation email and the ticket's status in your account, not a number from someone else's experience.
What's next
- Securing a fresh VPS: the first 10 minutes - set the server up so a lost-SSH ticket never has to happen in the first place.
- Changing a password in Ubuntu - if the problem is the password, not access to the server itself.
- PTR records and extra IPv4 addresses in WeaselCloud - a concrete example of a request that only goes through a ticket.
