Explained
You can't SSH into your server — what that actually means
Real server problems, translated into plain English by Onserva.
What you're seeing
The connection times out, or comes back with “connection refused”. You try again, because everyone tries again. Maybe the sites on the box are down too; maybe — more unsettling — they're still up while the door won't open. Either way you are locked out of the machine at exactly the moment you most want to look inside it.
What it actually means
Being unable to SSH in is a symptom, not a diagnosis — the door failing tells you little about why. In practice it is almost always one of four things, and they are worth checking in this order:
- 1. The disk is completely full. A full disk breaks logins in strange ways — the login process needs to write tiny files, and cannot. The cruel signature: sites often still serve, because they only read. If your monitoring showed the disk climbing this week, start here.
- 2. The machine ran out of memory. When memory is truly exhausted, everything struggles to do anything — including the program that answers your login. Connections crawl or time out, and the box feels “alive but unreachable”.
- 3. The network path changed. A firewall rule, a changed port, your own IP newly blocked by security software after failed attempts — the machine is fine, and the road to it is not.
- 4. The machine is off. Crashed, rebooting into trouble — or suspended by the provider. Billing suspensions are more common than anyone admits, and we say that with the humility of a company that once watched its own monitoring flag a fleet going silent over an unpaid hosting invoice.
What to do right now
- Use the provider's console. Every VPS provider gives you a screen-and-keyboard in the browser (DigitalOcean's Recovery Console, Hetzner's VNC console, and so on). It is the honest back door: it works even when the network path or SSH itself is broken, and reaching it tells you immediately whether the machine is running at all.
- From that console, check the two big suspects:
df -hfor a 100% disk,free -hfor exhausted memory. A full disk usually has a quick first-aid fix — clearing old logs or package caches frees enough to breathe, and the disk guide covers what is safe to clear. - If the console won't load either, stop debugging the machine — check the provider's status page, and then, honestly, your billing page.
- If the machine is healthy and the console works, the problem is the road: check the provider's firewall rules, and try from another network before assuming the server changed.
When to worry
A one-off with a found cause is a Tuesday. The pattern to take seriously is lockouts that keep happening: a disk that refills after every clearing, or memory exhaustion that returns weekly — those are trends, and trends were visible for days before the door stuck. The worst version of this story is discovering the cause only after a reboot wipes the evidence.
How Onserva handles this
When you cannot get in, the question is “what was happening on that machine just before?” — and something watching from outside is the only thing that can answer it. Onserva notices a server going silent within a couple of minutes and tells you, alongside the last readings before the quiet: a disk at 99% tells you it's cause number one before you have even opened the recovery console. And because the trends were being watched all along, the full disk and the memory squeeze usually page you days before they ever reach the front door.