Server unreachable, websites offline, or critical services no longer responding?
We investigate from the operating system level upward — Linux, a specific service, network configuration, or the hosting infrastructure underneath it — for VPS, cloud and dedicated servers on Hetzner, OVHcloud, Netcup, Contabo, IONOS, Scaleway, DigitalOcean, Vultr and others.
“Offline” isn’t always what it looks like
A server that appears completely offline isn’t always actually powered off. The first step is determining which layer has actually failed.
Ping works but SSH doesn’t — or nothing responds at all
When normal SSH access is unavailable, provider console or Rescue access may be required. Determining which side is responsible avoids unnecessary changes inside Linux when the real issue needs provider intervention.
Kernel updates, package upgrades, network changes, SSH updates, firewall changes, bootloader changes, PHP or database updates can all leave a server inaccessible. We investigate the change and restore a functional state, using a rescue environment if the OS won’t boot.
A single incorrect UFW, iptables, nftables, CSF, Cloudflare or provider firewall rule can block SSH, HTTP or HTTPS. If access is already lost, the provider console or Rescue System may be necessary to fix it.
What we check, by symptom
Can stop MySQL, break email, kill logging and fail backups. We find what consumed the space before deleting anything.
Server technically online, effectively unusable. We find what’s creating the load — not just reboot and wait.
Linux may kill MySQL, PHP-FPM or Redis under memory pressure. Not automatically a “need more RAM” problem.
Site looks “down” but Linux is fine — just the DB service. Restoring it can bring several sites back at once.
SSH may still work while the web server is stopped. We check config syntax and error logs before restarting repeatedly.
502/504 errors or very slow responses. We review pool config, worker limits and memory limits.
Exim/Postfix/Dovecot, mail queues, disk space, SSL, DNS. If websites and email fail together, it’s often OS-level.
Resource exhaustion, DB failure, broken plugin/theme, malware, disk full, Redis or SSL — full stack investigated.
When SSH won’t get us in
Depending on the provider: Rescue System, Recovery Console, KVM console, VNC console, serial console or a recovery ISO — all give access even when the installed OS can’t be reached normally.
Mounting filesystems, reviewing errors, checking capacity, recovering config, emergency backup before any repair tool runs. Boot failures can come from kernel problems, a damaged bootloader, bad /etc/fstab, missing disks or failed packages — a Rescue System can often repair configuration without a full reinstall.
On dedicated servers, we investigate software RAID, degraded arrays, failed disks, rebuild status and mount problems from the Linux side. When hardware needs replacing, the provider handles the physical work — we handle recovery before and after.
Sometimes — but it can hide the evidence
Repeatedly rebooting without understanding the problem can hide what actually happened. Where possible, we check memory, load, disk usage, processes, service status, kernel messages and logs first.
A reboot can restore service temporarily while leaving the real problem unresolved.
If Linux itself is fine but the infrastructure isn’t reachable, we gather MTR results, traceroute, packet loss, port connectivity, console output and RAID status — turning “the server is down” into a ticket the provider can actually act on.
Malicious processes, excessive outbound traffic, cryptominers or compromised WordPress can knock a server offline via resource exhaustion or provider abuse restrictions. We assess whether cleaning is realistic or a clean rebuild is safer.
Protecting recoverable data is often more important than immediately attempting aggressive repair operations.
Restoring availability is only the first part
- reviewing logs
- correcting configuration
- adjusting memory / PHP-FPM limits
- tuning MySQL
- improving firewall rules
- applying security updates
- configuring monitoring
- improving backup strategy
Monitoring — availability, HTTP/HTTPS, services, disk, load, memory, backup status — can reduce the time between a failure and someone noticing.
Faster diagnosis starts with the right details
Already tried something? Tell us what — it helps avoid repeating the same steps.
Server down normally falls under Emergency Support
Emergency Support, for critical incidents during normal availability.
Out-of-Hours Emergency Support — evenings, weekends, holidays.
Both subject to administrator availability — no guaranteed 24/7 coverage unless separately agreed. Full pricing →
Even during an urgent incident
IPs, hostnames, error messages, logs, screenshots and exact timestamps are faster to act on in writing than over the phone.
help@direktsupport.euPhone support is primarily for customers with an active monthly management plan.
More than 22 years of practical experience with Linux servers, hosting infrastructure, storage and production environments. When a server is down, the priority is straightforward:
identify the failing layer, protect the data, and restore the service safely.