AlexHost downtime, MIRhosting incident in June 2026
I host my website with AlexHost (the link is referral/affiliate), which I (not immediately but eventually) chose from this list of candidates. And it was all good until their Netherlands servers (where my website was hosted) went down on 2026-06-02.
The screenshot above is the status page that I had during the downtime.
Service outage announcement
On 2026-06-02 around 17:20 CET I got this outage announcement e-mail from AlexHost:
Dear Customer,We are writing to inform you of an emergency situation affecting our Netherlands location. All services are currently unavailable.
Our engineering team is actively working to identify and remediate the issue as quickly as possible. At this time, we do not have an estimated restoration window, but we will provide updates as the situation develops.
We sincerely apologize for the disruption this may cause to your operations. Our top priority is restoring full service at the earliest opportunity.
We will notify you as soon as services are restored or when a more accurate ETA becomes available.
Thank you for your patience and understanding.
Best regards, AlexHost Team.
By that moment my website was down for about 2 hours already, according to my monitoring: it stoped responding somewhere between 15:20 and 15:30 CET (I check availability with HEAD requests every 10 minutes).
Possible reason
According to this discussion, one possible reason for the AlexHost outage is the MIRHosting outage, because MIRHosting is an upstream for AlexHost. As one user said:
It's an outage of their NL upstream, MIRHosting. Multiple downstreams are affected.
https://bgp.tools/as/52000#downstreams
Most of their downstream prefixes are low visibility.Founder of MIR was arrested recently in connection with PQ.hosting sanction evasion shitshow.
Hopefully it’s not related and they are back online asap. Not a fault of AlexHost in particular, though.
Later in the thread AlexHost themselves confirmed that information.
A couple of days later another discussion (in russian) pointed out the same reason - MIRhosting servers were basically shut down (without any notice?) by nLighten data center in Netherlands (this one?), and that in turn brought down every other hosting service who was using MIRhosting as their upstream.
What to do now
Given the reason of the outage, I concluded that the chance of getting the servers back is very small. In the recent example with THE.Hosting (that article is also in russian) the outcome was that servers were lost for good(?) with all the data. And actually that incident also seems to be related to the MIRHosting troubles, because THE.Hosting is the “rebranded” name for PQ.Hosting, and, as it was pointed out above, the MIRHosting founder was arrested in connection with PQ.Hosting shenanigans, so it all can be parts of the same story.
Anyway, I was not at all concerned about losing my data on the server in Netherlands, because I had personal backups and expected to be able to restore from them with no problems (except for losing time). So I waited until the next day (2026-06-03), just in case, and then I wrote to AlexHost support asking for a new server in a different location, specifically in their main(?) data center in Moldova. To my surprise, even though they must have been overwhelmed with support requests from all their customers with servers in Netherlands, I got replies in about 10 minutes, and they quickly provided me with a new server in Moldova.
And so I started restoring my stuff from backups on the new server, which was also a great drill-not-a-drill scenario to see how good my backups really are. And they turned out to be pretty good, as I’ve managed to restore everything in about couple of hours. Too fucking bad that the freshest backup I had was 2 months old, but that’s my own goddamn fault, as I still hadn’t automated downloading of the backups from server. Either way, I haven’t lost anything really important: just some comments in Remark42 database and several GoAccess reports. The website came back at 18:40 (that is on 2026-06-03), so for me the total downtime was about 27 hours (most of which I was just waiting and hoping that the situation will resolve itself somehow).
Shortly after I got a new server in Moldova, AlexHost themselves started suggesting the same alternative to other customers:
An update regarding the ongoing outage at our Netherlands location.Your data is safe. All data remains fully intact and secure. This is a service availability issue, and restoring access is a matter of time. Our team continues to work on it as a top priority.
In the meantime, we are offering you the following options:
- Activate your server in Moldova location: we can provision you a new server in our Moldova location so you can resume your work as soon as possible. Then you will be able to decide if you want to remain in Moldova or move back into the Netherlands after the connection is restored.
- Request a refund: if you prefer, we are happy to process a full refund for the affected period. Simply reach out to our team and we will take care of it.
We sincerely apologize for the inconvenience and appreciate your patience. Whatever option you choose, our team is ready to assist.
To proceed with either option, please contact us via our live chat on alexhost_on Telegram: @alexhost_on
So they say that the data is “safe” and that they expect to eventually regain access to servers. But for me by now it doesn’t matter anyway, as I kissed that data goodbye and restored anew.
If anything, I don’t see this situation as AlexHost’s fault, so I won’t move to a different hoster from them. So far I’ve been quite satisfied with the services (contrary to an overwhelming amount of negative reviews on Trustpilot), and especially I like that price of 5 EUR per month (commitment of 62.4 EUR per year) for the 2/4096/40 server configuration. But we’ll see how it goes.
Temporary status page
As soon as I got the new server (and updated DNS records), I’ve set-up a temporary status page (screenshot) to let visitors know what’s going on and point them to the mirror which I still had running on GitHub.
Having the domain in .dev zone, I also had to issue and install a certificate first, otherwise even a simple static page wouldn’t work, as HTTPS is an absolute requirement in that zone. Fortunately, I already had the procedure well tested with a Docker container for acme.sh, so the whole thing barely took 5 minutes.
Of course, a better way would be to have a load-balancer/failover thing, then my visitors would have started getting a status page right after the main website went down, but for me such a setup is a bit of an overkill, so I did not consider it in past and probably won’t do it now either.
As for the status page itself, I decided to redirect everything to it, no matter what website URL was actually requested:
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name decovar.dev;
ssl_certificate /path/to/certificates/decovar.dev/fullchain.pem;
ssl_certificate_key /path/to/certificates/decovar.dev/key.pem;
location / {
root /var/www/status-page;
index index.html;
try_files $uri $uri/ /index.html;
}
}
which, I imagine, is very bad for indexing the website by crawlers from Google and other search engines. If anyone knows a better way to handle a temporary status page and not ruin the existing indexing data for the website in search systems, please leave a comment about that. I reckon, at least I should have done it with a 302 redirect, but I realized that only when I had already restored the main website, so there was no need for a status page anymore.