How to check whether the vps status is online or offline
This guide shows you how to confirm whether a VPS is online or offline by checking Virtualizor, testing network connectivity with SSH, opening a VNC console and inspecting system logs. You will learn to distinguish between a powered-down VPS, a booted operating system and network reachability issues.
How to check whether the VPS status is online or offline
Check the power state in Hostworld’s Virtualizor panel first. If it shows the VPS running but you cannot reach it, test SSH from your computer and open the Virtualizor VNC console to see whether the operating system has booted. Inside the VPS, use systemctl and the journal to confirm the system state and what happened during boot.
Before you start
- You will need access to the Hostworld client area to reach Virtualizor. You can log in at portal.hostworld.uk. The client area is WHMCS. From there you open Virtualizor to manage the VPS.
- Have the VPS IP address and the SSH username ready, for example root or another admin user.
- Virtualizor shows and controls the VPS power state. This is the definitive source for online versus offline at the hypervisor level.
- Do not rely on ping alone. ICMP Echo is often filtered, so no ping replies do not prove a VPS is offline.
- Avoid destructive actions while investigating:
- Do not click Re‑install OS in Virtualizor. That wipes the VPS and all data.
- Avoid Power Off where possible. That cuts power hard. Prefer an in‑guest shutdown or the panel’s Stop or Restart.
- If the network is unavailable, Virtualizor provides a VNC console and a Rescue Mode boot. These let you see if the OS is up and, if not, repair it.
- If you cannot reach Virtualizor or you are unsure what you are seeing, open a support ticket. Tickets are logged against your account.
Step 1: Check the power state in Hostworld’s Virtualizor
Look at the VPS entry in Virtualizor. The Enduser List VPS page shows each VPS with Start, Stop, Restart and Power Off controls. This page also shows whether Virtualizor believes the VPS is running or stopped. If it shows running, treat the machine as online at the hypervisor. If it shows stopped, it is offline until you start it.
Outcome to aim for: confirm the panel reports the VPS as running. If it is stopped, start it here and wait a minute for boot to complete before testing network access.
- Prefer the panel’s Start, Stop, Restart for a graceful change of state.
- Avoid Power Off unless the VPS is completely unresponsive and VNC confirms it is hung. It is a hard cut and risks data loss on recent writes.
- Do not use Re‑install OS while checking status. That recreates a fresh VPS without your data.
For automation and monitoring: Virtualizor exposes a VPS Status API endpoint. That confirms the platform tracks a formal online or offline state and can report it programmatically.
Step 2: Probe network reachability with SSH from your computer
This tests whether the VPS is reachable over TCP and whether an SSH service is answering. It is a faster and more reliable indicator than ping.
Run this from a terminal on your workstation or another server. The options set a five second timeout and make SSH fail fast without prompting for passwords.
AlmaLinux 9
ssh -o ConnectTimeout=5 -o BatchMode=yes root@YOUR_VPS_IP
Ubuntu 24.04
ssh -o ConnectTimeout=5 -o BatchMode=yes root@YOUR_VPS_IP
- If you see a host key prompt or a password or key prompt, the VPS is online from the network’s point of view and port 22 is reachable.
- If it times out or says connection refused, keep going. That is not final proof of an offline VPS.
You can also send a small number of ICMP Echo requests as a hint. Remember that lack of replies is not proof of downtime because ICMP may be filtered by a firewall.
AlmaLinux 9
ping -c 3 YOUR_VPS_IP
Ubuntu 24.04
ping -c 3 YOUR_VPS_IP
- Exit code 0 means replies were received. Exit code 1 means no replies. Exit code 2 means another error. Use this as supporting evidence, not a verdict.
Step 3: Open a Virtualizor VNC console if SSH will not connect
Use Virtualizor’s built‑in VNC viewer to see the console as if you were at the screen. This confirms whether the kernel has booted and whether the system is responsive even when the network is down.
- If you see a normal login prompt, the OS is up. Investigate networking or SSH configuration next.
- If you see emergency mode, a stuck boot, or a crash loop, the VPS is online at the hypervisor but the OS is not healthy. Stay in VNC to repair, or use Rescue Mode in a later step.
Step 4: Confirm the OS state with systemd
This asks systemd whether the system reached a healthy state. The command returns success only when the system is running. With the wait flag it blocks until a final state such as running or degraded is reached.
AlmaLinux 9
systemctl is-system-running --wait
Ubuntu 24.04
systemctl is-system-running --wait
- If it prints running, the OS is up.
- If it prints degraded, the OS is up but some units failed. It is still online.
- Any other state indicates startup is incomplete or in trouble. Check logs in the next step.
Step 5: Review boot history and current boot logs
These commands tell you when the server last booted and show messages from the current boot. They help you separate network issues from actual downtime or crash loops.
Show the last boot time recorded by the kernel.
AlmaLinux 9
who -b
Ubuntu 24.04
who -b
List recent reboots recorded by the accounting logs.
AlmaLinux 9
last reboot
Ubuntu 24.04
last reboot
Show logs for the current boot. If the system did not reach running, focus on errors at the end and on failed service start messages.
AlmaLinux 9
journalctl -b
Ubuntu 24.04
journalctl -b
To view the previous boot’s logs, use the negative boot offset. This only works when persistent journalling is enabled. On AlmaLinux 9 and Ubuntu 24.04 the default often does not persist logs across reboots. The next step shows how to enable persistence.
AlmaLinux 9
journalctl -b -1
Ubuntu 24.04
journalctl -b -1
Step 6: Enable persistent journals so previous‑boot checks work
This makes systemd store logs under /var/log/journal so they survive reboots. It lets you use journalctl -b -1 reliably.
Create the journal directory and restart the journald service.
AlmaLinux 9
mkdir -p /var/log/journal
systemctl restart systemd-journald
Ubuntu 24.04
mkdir -p /var/log/journal
systemctl restart systemd-journald
Alternatively, you can set Storage=persistent in /etc/systemd/journald.conf if you prefer configuration over the directory method. Either approach enables persistence.
Step 7: Check SSH and networking inside the VPS
If VNC shows the OS is up but SSH from outside fails, confirm that sshd is listening and that the network stack considers links operational.
List TCP listeners and filter to port 22 to verify whether the SSH daemon is bound. If there is no output, sshd is not listening on 0.0.0.0:22 or [::]:22.
AlmaLinux 9
ss -tln 'sport = :22'
Ubuntu 24.04
ss -tln 'sport = :22'
Summarise link states with networkctl. This reports each interface’s operational state and can highlight when the network is up but not fully online.
AlmaLinux 9
networkctl
Ubuntu 24.04
networkctl
To wait for the system to consider networking online before starting your own checks or services, use the wait helper with a timeout. It treats online as an operational state at least degraded.
AlmaLinux 9
systemd-networkd-wait-online --timeout=15
Ubuntu 24.04
systemd-networkd-wait-online --timeout=15
Step 8: Use Rescue Mode if the OS will not boot
When the VPS appears offline and the VNC console shows repeated boot failures, enable Rescue Mode in Virtualizor. This boots a rescue image, allows you to access the disks and repair configuration. When finished, disable Rescue Mode and boot the normal OS again.
Step 9: Decide based on the evidence or ask for help
- If Virtualizor says running and SSH connects or prompts for a credential, the VPS is online. Investigate application issues next.
- If Virtualizor says running and VNC shows a login prompt, the OS is up. Focus on networking and firewall configuration.
- If Virtualizor says running and VNC shows crash or emergency output, the OS is not healthy. Use logs and Rescue Mode to repair.
- If Virtualizor says stopped, start the VPS and repeat the checks.
If you are stuck at any point, or the Virtualizor panel itself is unreachable, open a support ticket. Tell us what you saw in Virtualizor, the SSH and ping results, and any errors from the VNC console. That helps us diagnose faster.
What next
- Browse our VPS guides for more on managing and troubleshooting Linux servers at Hostworld.
- Need a new server or more capacity near London? See our UK location on the Linux VPS page.
- If you prefer step by step in our panel rather than a broad guide, check the how‑to collection linked from our VPS guides. It covers Virtualizor tasks click by click.
Common questions
Virtualizor shows my VPS as running but SSH will not connect. Is it offline?
No. The hypervisor has the VPS online, but the network path or the SSH service may be the issue. Confirm over VNC that the OS has booted. Inside the VPS, check that sshd is listening with ss and that networkctl shows the interface up. Then review journalctl -b for any service failures.
Ping does not reply. Should I reboot?
Not based on ping alone. ICMP Echo is often filtered by host firewalls or by security groups, so lack of ping replies is not a reliable indicator. Use the SSH reachability probe with a five second timeout first, then the VNC console if SSH fails.
Is it safe to use Power Off if the VPS looks hung?
It is a last resort. Power Off in Virtualizor is a hard power cut. Linux filesystems journal metadata, but recent writes can be lost and, in some modes, incorrect file data can appear. Try a graceful Stop or an in‑guest reboot from VNC first. Use Power Off only when the console is unresponsive.
Can I check status automatically?
Yes. Virtualizor provides a VPS Status API endpoint. That lets monitoring or automation query the platform’s view of each VPS’s state. For in‑guest checks, use systemctl is-system-running with a timeout in your scripts to confirm the OS reached running.
journalctl -b -1 says there is no persistent journal. What now?
Enable persistent journalling so previous boots are recorded. Create /var/log/journal and restart systemd-journald. Then trigger another reboot and you will be able to read the prior boot’s logs with journalctl -b -1 on both AlmaLinux 9 and Ubuntu 24.04.