I’m sharing a brief post‑mortem of a severe crash (Error 500) that occurred at 6:31 am on my hosting, in case it helps others facing the same symptoms.
Here’s a point‑by‑point summary of what happened:
Affected infrastructure: I have two sites configured on the same OVH shared hosting (the main lecomptoirdetoamasina.fr running PrestaShop 1.7.8, and wayapi.fr WordPress). Because they share the same physical resources, when the hosting saturated, both sites displayed a 500 Error at the same time.
Trigger (06:31): The failure wasn’t caused by human error or an update, but by a massive traffic attack. I endured an ultra‑aggressive crawl from indexing bots (mainly PetalBot and MJ12bot), with a staggering spike of over 8 000 requests in a single hour.
Target (Weak point): These bots didn’t just read static pages. They repeatedly bombarded the dynamic requests of my PrestaShop: the search bars and category filters. These are the queries that put the most load on the database.
I noticed an increase in 500 errors on the OVH back‑office between 06:31 and 12:00.
I didn’t hit the private SQL limit, but the shared server struggled; I couldn’t access the back‑office, and the .htaccess file has been unchanged for four months.
To check if it was an attack, I put the site behind Cloudflare for four hours, but it gave no feedback; I launched a restore, but that got stuck and I saw issues at OVH—this is the first time I’ve encountered this.
The WordPress site wayapi.fr is a control site; it doesn’t receive traffic but sends me a message if it has a problem.
From what I can see, the spike of 8,000 requests in one hour has consumed the resources allocated to your hosting, causing the service to go down. Generally, in a shared environment, resources are limited and not designed to withstand this kind of brute‑force attack against PrestaShop dynamic scripts.
The first thing you should do is check the access logs of your hosting in the OVH client area. Identify the exact User-Agent of the bots that are generating the massive traffic, such as PetalBot or MJ12bot. This will give you precise information to know what you’re dealing with.
You can create direct rules in the .htaccess file so that the server returns an error code to these bots before the site gets to process the request. The web server returns an error that consumes almost no resources, easing the load on the database and PHP processing.
The solution you’ve implemented is the most advisable To prevent future attacks, make sure Cloudflare is correctly configured in “Full Protection” mode. You can add firewall rules to block the problematic User-Agents at the network level.
Let us know how it goes, best regards.
Sergio Turpín
I have 500 GB of space now 1.5 TB so there is a problem, I’m worried with the weekend coming; the site has been offline for 35 hours. The thing I don’t understand is why I can still get the photos.
The .htaccess file, I can upload it once the problem is resolved; do you think it’s caused by me or OVH?
If they are really official bots you’ll get away with it... In the case of an aggressive scraper (that spoofs its UA) that just wants to drain the resources of your hosting, good luck.
I'm getting back to you: the problem is with OVH; they have an issue with PHP execution. We don't know when the sites will be back, and I'm not the only one affected.
I confirm that the problem comes from OVH and the PHP engine; it was an intervention by a Tier‑3 administrator, I think, who resolved the issue. It seems to be widespread—I’m getting the impression that if you’re caught up in it, it’s a nightmare. He’s got a lot of bugs on my hosting, and I’ve had two tasks failing since Thursday.
To prevent future attacks, make sure Cloudflare is correctly configured in “Full Protection” mode. You can add firewall rules to block the problematic User-Agents at the network level.
