What to do when your hosting
provider has an outage
OVHcloud, Hetzner, Scaleway, Contabo or IONOS: the server stops answering, and the first question is not "how do I fix it" but "whose outage is it". The six steps in order, and what is better left alone in the meantime.
Contents
1. The short answer: six steps
Whatever the provider, the order is the same. The first two steps keep you from making things worse; the others shorten the outage.
Find out whether the outage is at the provider or on your side
Check the provider's status page and test the server from another network — a phone on 4G is enough. All your servers silent and an incident listed: it is the provider. A single server silent and a green status: it is probably yours.
Do not reboot, reinstall or restore blindly
During a provider incident, a forced reboot fixes nothing and can damage a database that was writing. A reinstall from the customer panel wipes the disk.
Open a ticket that saves time
Server ID, IP address, exact start time, what you have already tested, and a traceroute or mtr run from outside. A ticket saying "my server does not work" comes back with questions.
Tell your users
A short message, on a channel that does not depend on the failed server: mail hosted elsewhere, an external status page, a social network. Saying you know beats saying nothing.
If the outage lasts: fail over, or restore elsewhere
If the architecture allows it, now is the time to fail over to a second site. Otherwise the only way out is to bring the service back up elsewhere, from a backup that was not stored at the failing provider.
Afterwards: write down what happened
Timeline, duration, the cause given by the provider, and above all what would have prevented or shortened the outage. That document is what justifies — or not — investing before the next one.
2. The provider or your server? Reading the symptoms
Three observations are usually enough: what the status page says, how many machines are affected, and what still answers — the rescue console, the private network, the public address.
| What you see | Likely diagnosis | First move |
|---|---|---|
| All your servers at this provider are unreachable, the status page lists an incident | Provider outage | Follow the status page, open a ticket if your zone is not listed, tell your users |
| A single server stops answering, the status page is green | Your server: full disk, stopped service, hung kernel, firewall | Open the rescue console from the customer panel: if it answers, the fault is on your side |
| The server answers on the console, not on the network | Network configuration, firewall, or a localised network incident | Compare with another server in the same datacenter, run a traceroute from outside |
| The servers answer on the Internet but no longer see each other | Private network down: a cluster can end up split in two | Do not force quorum blindly — see our field report below |
| Everything answers, but the site is slow or returns errors | Rarely the provider: saturation, database, application | Look at load and logs before blaming the infrastructure |
| Green status, but other customers report the same symptom at the same time | Incident under way, not yet published | Retest, then open a ticket: a status page is kept up to date by people |
The private network case is the most misleading: seen from the Internet, every machine looks healthy, while the cluster no longer works. We lived through it on a Proxmox cluster at OVHcloud, when the vRack stopped carrying traffic between the nodes: what happened and how we fixed it, second Corosync ring included.
3. The five providers' status pages
Addresses checked on 11 September 2026. Note your provider's before you need it: during an outage is not the time to look for it. The private network is listed separately because it can fail while the rest of the infrastructure is fine.
| Provider | Official status page | Private network to watch too |
|---|---|---|
| OVHcloud | www.status-ovhcloud.com — one page per product line: Bare Metal, Public Cloud, Web Cloud | vRack |
| Hetzner | status.hetzner.com | vSwitch (dedicated servers), Networks (Cloud) |
| Scaleway | status.scaleway.com | Private Networks |
| Contabo | contabo-status.com | Private Networking (add-on) |
| IONOS | www.ionos-status.com | Depends on the plan |
A status page says what the provider knows and has published. It says nothing about your server in particular: an incident limited to one chassis or one rack is not necessarily listed, and publication follows detection by a few minutes. A green status does not clear the provider; it tells you to look at your own server first.
4. What is better left alone during the outage
Provider outages rarely lose data on their own. It is what gets done in a hurry, to "do something", that turns an interruption into a loss.
Reinstalling from the customer panel
A reinstall wipes the disk. It never fixes a provider outage, and it makes unrecoverable what the outage had left untouched.
Chaining forced reboots
If the datacenter or the network is at fault, the server comes back in the same unreachable state. If a database was writing when the power went, every hard stop adds a risk of inconsistency.
Restoring on top of production
Restoring a snapshot onto the original server before understanding the incident overwrites everything written since the last backup. If you must restore, do it alongside, not on top.
Changing DNS in a rush
Pointing records at a standby machine that was never tested moves the problem, and rolling back depends on the record lifetime (TTL) set long before the outage.
5. If the outage lasts: fail over, or restore elsewhere
When the outage settles in, the question changes: it is no longer "when will the provider be done", but "can we serve without them". The answer depends entirely on what was prepared beforehand.
If the architecture allows it: fail over
A service spread over two sites, or two providers, can carry on without waiting for the repair. With a two-layer architecture, failover is automatic; with internal multi-site anycast, traffic is served by whichever site is still reachable.
Otherwise: restore elsewhere
Without a second site, the only way out is to bring the service back up on another machine, ideally at another provider, from a backup that was not stored at the one that failed. The full method is in our Proxmox disaster recovery plan.
A backup kept in the same datacenter as production disappears with it. That is the lesson of the fire at the OVHcloud datacenter in Strasbourg in March 2021: backups stored on the same site were lost along with the servers. Our NimbusBackup off-site backup is hosted at Equinix Paris, outside your provider's infrastructure.
In both cases, what decides is not the quality of the provider but having tried beforehand: a failover never tested and a restore never performed fail on the day they are needed.
6. What nobody can do during a provider outage
Let us be plain about it: no managed services provider repairs OVHcloud's datacenter, Hetzner's network or Scaleway's power supply. When the outage is at the provider, the repair is at the provider.
What a managed services provider does in the meantime is less spectacular, and more useful:
- establish within minutes that the fault is not on your server, and show it;
- open and follow up the ticket at the provider, with the details that avoid back-and-forth;
- keep you informed, so that you can inform your own customers;
- trigger the failover or the restore elsewhere, if they were prepared;
- check on the way back that everything returned: services, replication, backups, certificates.
For our on-call customers, that handling is what the response time (GTI) commits to — 4h or 1h depending on the level, 24/7 — not the duration of the provider's outage, which nobody controls. The real lever sits before the incident: a backup outside the provider, and an architecture that does not depend on a single site.
7. What about compensation?
It depends on the SLA of your plan, and it is read before the outage. In most hosting contracts, compensation takes the form of a credit calculated on the price of the unavailable service — not on the revenue you lost. For a server billed a few tens of euros a month, the credit bears no relation to the cost of a day of downtime, which you can estimate with our downtime cost calculator.
Claim it anyway, with your timeline: it is also what documents the incident for what comes next.
8. After the outage: what would have prevented it
The post-mortem is not there to find a culprit at the provider. It is there to decide what you change, now that you know what an outage really costs.
A backup outside the provider
It is the condition for restoring elsewhere. Check where your backups go today, and when they were last restored.
A second site, if the business justifies it
Not every application needs one. Those whose downtime costs more than a doubled infrastructure do: the four high-availability architectures, from the simplest to the most robust.
Someone who picks up at 3am
Diagnosis, ticket, failover: it takes someone awake. Our 24/7 on-call starts at €90 per server per month with a 4h response time, and takes over your server where it already runs, with no migration.
9. Frequently asked questions
How do I know if OVH is down?
Check the OVHcloud status page, www.status-ovhcloud.com, which publishes incidents per product line: Bare Metal for dedicated servers, Public Cloud, and Web Cloud for web hosting. Then test your server from another network; a phone on 4G is enough. If all your OVH servers are unreachable and an incident is listed for your datacenter, the outage is at OVH. Remember the vRack too: if your servers answer on the Internet but no longer see each other, it is the private network that is down.
Hetzner is down: what should I do?
Check status.hetzner.com, telling dedicated servers apart from the Cloud offer, which do not share the same incidents. If an incident covers your datacenter, do not reinstall anything and do not keep rebooting: open a ticket with the server ID, the IP address, the start time and a traceroute, then tell your users. If the outage lasts and your service allows it, fail over to another site or restore elsewhere from a backup stored outside Hetzner.
My Contabo server is not responding: is it Contabo or my server?
Look at contabo-status.com first. If no incident is listed, open the rescue console from your customer panel: if the system answers on the console but not on the network, the cause is almost always on your side, such as a firewall, a full disk or a stopped service. If the console itself is unreachable and other customers report the same symptom, open a ticket: the status page can lag a few minutes behind reality.
Scaleway reports an incident: is my data at risk?
A network incident or a management interface outage does not wipe disks: most of the time the data is intact but unreachable. The danger lies mostly in what gets done in a hurry, such as a reinstall or a restore on top of production. Check status.scaleway.com, wait until the incident for your zone is closed, then check your services and databases. If the site itself is lost, only a backup stored outside Scaleway lets you start again.
Should I reboot the server from the customer panel during an outage?
Not while the status page lists an incident for your zone: the server will come back in the same unreachable state, and a hard stop while a database is writing adds a risk of inconsistency. A forced reboot makes sense when the status page is green, only your server is affected and the rescue console shows a hung system. And never a reinstall: it wipes the disk.
Does the provider owe me compensation?
It depends on the SLA of your plan, which is worth reading before the outage. In most hosting contracts, compensation takes the form of a credit calculated on the price of the unavailable service, not on the revenue you lost. For a server billed a few tens of euros a month, the credit bears no relation to the cost of a day of downtime. Claim it anyway, with your timeline of the incident.
Can a managed services provider fix my hosting provider's outage?
No, and none can: when the outage is in the provider's datacenter or network, the repair is at the provider. A managed services provider establishes that the fault is not on your server, opens and follows up the ticket, keeps you informed, triggers the failover or the restore elsewhere if they were prepared, then checks that everything came back. For our on-call customers, the 4h or 1h response time (GTI) covers that handling, not the duration of the provider's outage.
Prepare for the next outage now
Tell us which provider runs your servers and what they carry. We will reply with what is missing today to get through a provider outage: backup, second site, on-call.
Request a quote