Your VPS appears down — diagnostic checklist before opening a ticket

The single most-opened ticket against LYLIX is "my server is down." Most of the time, the server is fine — the connection between you and it isn't. Sometimes the server really is in trouble. This article walks you through the five-minute checklist that distinguishes the two so you can either fix it yourself or open a ticket with the right information up front.

If you just want the order of operations: check the LYLIX portal first, then check from a third-party network, then check your own connection, then check the VPS itself. Everything else on this page is the detail behind those four steps.

Step 1 — Check the LYLIX portal first

Log in to the customer portal. The service status indicator on your VPS's dashboard reads from the hypervisor, not from your network path — so even if you can't reach the VPS over the public internet, the portal will still tell you whether the VM is running.

• Status: Running — the VM is up. The problem is the network path between you and it, or something inside the guest. Skip to step 2.
• Status: Stopped / Suspended — the VM isn't running. Either it was shut down (by you, by an unpaid invoice, by an OS panic) or there's a hypervisor issue. Check your billing status and most recent emails first; if neither applies, jump to step 4.
• No status / portal won't load — the portal itself is unreachable. Check status.lylix.net for any announced infrastructure work.

If the portal shows your VM running and shows recent resource graphs (CPU/RAM/network ticking along), the VM is genuinely fine and the issue is between you and it.

Step 2 — Check from a third-party network

You need to know whether the VPS is unreachable from everywhere or just from your network. A few quick options:

• Your phone on cellular data — quickest sanity check. Open the portal, try the VPS web service (if any), try the SSH IP via a Termius/Blink-style app. If it works on cellular but not on your office wifi, your office is the problem.
• An online "is it up?" tool — search for "ping from multiple locations." Several free services will ping or HTTP-check your VPS from a dozen global points of presence in seconds.
• A second VPS or a friend's connection — most reliable. Run ping, mtr, or curl from somewhere unrelated.

If the VPS responds from third-party networks but not from yours, the problem is your local network, your ISP, or a route between them and our network. Open a ticket with your ISP, not with LYLIX — we can't fix a route that doesn't pass through us.

Step 3 — Run mtr or traceroute

If the VPS is unreachable from multiple places, run a path trace. On Linux/macOS:

mtr -rwbzc 50 <your-vps-ip>

On Windows: tracert <your-vps-ip> (or download WinMTR).

What you're looking for:

• Packet loss at the last hop only — the path is fine, the VPS itself is dropping. Usually means the guest is overloaded or down at the kernel/network level. Skip to step 4.
• Packet loss starts mid-path and stays — a router upstream is the problem. Note the IP/hostname where it starts and include that in your ticket. We can often route around it.
• Clean path, every hop responds — the network is fine. The problem is application-layer (SSH daemon crashed, web server crashed, firewall blocking).

Step 4 — Get into the VPS another way

If the public network path to your VPS is broken or the SSH daemon isn't responding, use the browser console.

• Portal → your VPS → Console tab.
• This gives you a graphical console attached directly to the VM, bypassing the network entirely. You can log in as root with your VPS password.
• Once in, check the obvious: df -h (disk), free -m (RAM), uptime (load), systemctl status sshd (is SSH running?), journalctl -xe (recent errors).

The single most common finding via console: the disk is full, which prevents new SSH sessions from starting. See Disk full cleanup for the standard recovery flow.

Step 5 — Restart the VM (if needed)

If the VM is unresponsive in the console too, or if a service is wedged and won't recover, restart from the portal:

• Portal → your VPS → Reboot. This is a graceful shutdown + start.
• If that doesn't work, Stop then Start. Acts like pulling the power cord and plugging it back in.

A VM that won't come back from a reboot is the point at which you should open a ticket — that's almost always something the LYLIX team needs to investigate on the hypervisor.

When you do open a ticket

Open it in the Virtual Private Server or Emergency department. Include:

• The VPS hostname and IP.
• What you've tried (steps 1-5 above). Tell us what worked and what didn't — "portal shows running, ping fails from my office AND from my phone, mtr shows clean path, browser console responds but SSH from outside doesn't" is gold. "It's down" forces us to repeat all of step 1-5 ourselves, which adds an hour to the response.
• The output of mtr if you ran it.
• Whether anything changed recently — software install, OS update, firewall rule, configuration push.

See Opening a ticket that gets fixed fast for the longer template.

Common patterns we see

• "Server is down" — actually a fail2ban self-lockout. You typed the SSH password wrong a few times; fail2ban added your office IP to its block list. Browser console works fine. Fix: unban your IP (fail2ban-client unban <ip>) and use a key.
• "Server is down" — actually disk full. Browser console responds but very slowly, SSH from outside rejects new connections. df -h shows root at 100%. Usually /var/log or a runaway PBX call recording.
• "Server is down" — actually the upstream carrier. Your VPS is fine; phones can't reach it because their SIP trunk to a separate carrier is broken. SIP carriers occasionally have regional outages that look like "the PBX is down."
• "All my VPSes are down" — usually the customer's ISP. Multiple VPSes hosted at LYLIX going dark from one location at the same time is almost always a problem on that customer's end, not ours.

Running through this checklist before opening a ticket typically resolves about a third of "down" cases in under five minutes. For the rest, the diagnostic information you collected gives the LYLIX team a head start.