Article 5.6 - VPS Completely Unresponsive — Diagnostic Flow
Short answerCheck Client Area status → Boot/Reboot → noVNC (login vs panic vs frozen) → guest logs → disk full → OOM — then ticket with findings.
Overview
Work top-down: platform power state, then console, then guest OS resources. Most issues are guest firewall, full disk, or OOM — not hypervisor failure.
Diagnostic flow
| Step | Action | If you see… |
|---|---|---|
| 1 | Client Area status | Offline → Boot; Active but hung → Reboot |
| 2 | noVNC console | Login prompt → OS up (check SSH/firewall); kernel panic → ticket; black/frozen → Reboot |
| 3 | Logs via noVNC | journalctl -xb -p err, dmesg | tail -40, df -h, free -m |
| 4 | Disk full | du -sh /* 2>/dev/null | sort -rh | head -10; trim large logs |
| 5 | OOM | dmesg | grep -i oom — add swap or upgrade RAM |
When to open a ticket
Kernel panic on console, repeated Failed tasks in Task History, or Active VPS with no console output after reboot — include service ID, screenshots, and log excerpts (redacted).
Frequently Asked Questions
Ping fails but VPS Active?
ICMP may be blocked by guest firewall — test SSH/RDP port or use noVNC.
Difference from Article 5.1?
Article 5.1 is the quick checklist; this article is the full decision tree with guest OS commands.
Related Articles
Need More Help?
Search this knowledgebase for related guides. If the issue persists, open a ticket at billing.vpsgrid.net with your service ID, primary IP, and steps already tried. See What Information to Include in a Support Request and Security Responsibilities on Unmanaged VPS for scope and required details.
Was this answer helpful?
