Checking platform status

When something stops working, the first question is whose side it is on. The dashboard carries a status card, and it answers a narrower question than most people read into it. This page covers what it does answer, and then how to check your own server, which is usually what you came for.

What the status card checks

Systems status reports whether the systems the panel itself leans on answered a request. That is the whole of it. A row reading operational means the request came back, not that everything behind it is working normally.

It is worth one glance in one situation: when the card reports Degraded, expect the panel to misbehave. Invoices may not load, power buttons may fail, and retrying is reasonable. That is a real signal about the panel.

Dashboard / Systems statusExample view

Systems statusClouduxe core services · liveAll operationalBillingInvoices, payments & walletOperationalChecked: did it answer a request?Server controlProvisioning, power & consoleOperationalChecked: did it answer a request?DDoS protectionAlways-on edge mitigationOperationalNot checked: always reads Operational

Never on this cardYour server: its power, its disk, whether it is reachable, your IP, or the filtering in front of it.

What it does not tell you

It is not a measurement of your server, your IP, or the traffic filtering in front of it. Your server can be powered off, out of disk, or unreachable from the internet while every row on the card reads operational. Nothing on the dashboard watches your machine on your behalf.

So do not use the card to decide whether your own service is up. Use the checks below, in order. They take a couple of minutes and they tell you something the card cannot.

Checking your own server

1. Read the power state

   The power bar at the top of the server tells you what the hypervisor thinks the machine is doing. Only running and stopped are settled states. While a server is starting, stopping, or restarting, the buttons are disabled and a chip reads Working… until it settles.

   If every power button is greyed out and it stays that way, that is usually an account state rather than an outage: a suspended service is locked, and the services list shows a banner explaining it. Check your invoices before anything else.

   See Power controls for what each button does.

2. Read the gauges, knowing what they measure

   The CPU usage, Memory, Storage, and Bandwidth rings refresh every 15 seconds. CPU, memory, and storage are reported by the guest agent running inside your VM, so they tell you about the operating system, not about whether the port your players use is reachable.

   Two things to know before you trust a number here:

   • If the guest agent is not running, Storage shows a dash and Memory falls back to the figure you were allocated, labelled Allocated. That is "not reporting", not "nothing in use".
   • A failed refresh is silent, and the last good numbers stay on screen. The live chip only flashes on a successful refresh, so its absence is the only sign you are reading stale figures.

   Server overview covers each figure in full.

3. Open the console

   The console is the check that settles it. It attaches to the machine itself rather than going over your network path, so it works even when SSH and RDP do not.

   If you get a login prompt, the VM is running and the operating system is up. The problem is then somewhere between the internet and your service: a firewall rule, a service that is not listening, or your own connection. If the console cannot connect at all, you get:

   Couldn't establish the console session. VNC isn't responding for this server yet. Try again, or open a support ticket if it persists.

   The console is only there for services that have a VM. A standalone DDoS-protected proxy subscription does not have one.

   See Console access.

4. Rule out your own connection

   Before concluding anything, try from a second network and a second device. A route problem on your own connection, or a block by your own ISP, looks exactly like a dead server from where you are sitting.

   If SSH or RDP fails but the console shows a login prompt, the machine is fine and something between you and it is not. Check the address and credentials in Connecting to your server, then check the Firewall tab for a rule covering the port you are using.

When to conclude it is on our side

Open a ticket when one of these is true:

• The power state reads running, or the console shows a login prompt, but nothing reaches the server from more than one network, and no rule of yours explains it.
• The console will not connect and retrying does not change that.
• The panel itself is failing actions, power commands or invoice loads, and Systems status reports Degraded.
• You send a power command and the state never settles, even after a reload.

If players can reach the server sometimes but not reliably, or a subset of them cannot get in at all, start with When players cannot connect instead. That pattern is usually a rate limit or a rule, and it is faster to fix yourself than to report.

When you do open the ticket, attach the service with Related to (optional) and carry over what you learned above: the power state, whether the console gave you a login prompt, the exact error, when it started, and what changed just before.

Related