Erreur 508 Resource Limit Reached : causes et solutions

Erreur 508 Resource Limit Reached : ce que ça veut dire

L’erreur 508 « Resource Limit Reached » signifie que votre compte d’hébergement mutualisé CloudLinux a atteint un plafond de ressources, le plus souvent le nombre de requêtes PHP simultanées (entry processes). Le serveur refuse alors les nouvelles visites, sans toucher aux autres comptes. Le site repart quand la charge retombe.

Prenons un cas typique (illustratif) : un site WordPress tourne normalement, puis affiche « Resource Limit Is Reached » pendant quelques minutes à chaque pic, puis revient seul. C’est le comportement normal d’une limite par compte. L’erreur se règle, et elle vient presque toujours de ce que fait le site, pas d’une panne de l’hébergeur.

Un point de vocabulaire évite de perdre du temps. Dans la norme, le code 508 est « Loop Detected » et appartient au protocole WebDAV (MDN, 508 Loop Detected, RFC 5842). Le « 508 Resource Limit Reached » de CloudLinux n’a aucun rapport : c’est un usage propre à l’hébergeur. Un outil de monitoring qui lit « 508 » selon la norme peut donc vous envoyer sur une fausse piste.

Si la Search Console vous a signalé un 509, notez que ce code n’est pas standardisé. Certains hébergeurs l’utilisent pour une limite de bande passante, d’autres autrement : demandez au support ce qu’il signifie chez lui.

Pourquoi ça arrive

Un LVE (Lightweight Virtual Environment) est le conteneur que CloudLinux crée pour chaque compte d’hébergement afin d’y appliquer des plafonds de ressources. Un entry process (EP) désigne un processus Apache qui entre dans ce conteneur, c’est-à-dire une requête PHP en cours de traitement. Le compteur monte à chaque nouvelle requête et redescend quand elle se termine. Quand la limite est atteinte, mod_hostinglimits ne peut plus admettre de processus et renvoie le 508, sans affecter les autres comptes (source : documentation CloudLinux OS, 2026).

CloudLinux surveille plusieurs plafonds en parallèle, et le message d’erreur dépend de celui qui saute :

Les valeurs dépendent de l’offre. Chez un hébergeur documenté publiquement, les offres d’entrée démarrent à 30 EP et 100 processus, et ce comportement varie d’un hébergeur à l’autre (source : Serversaurus, 2026). Les sessions SSH et les crons simultanés comptent aussi dans les EP.

Les causes les plus fréquentes :

• Robots et crawlers qui enchaînent des centaines de requêtes non mises en cache.
• Une extension gourmande (sauvegarde, recherche, statistiques, import, boutique complexe).
• WP-Cron qui se déclenche à chaque visite, ou des crons qui se chevauchent.
• Un pic de trafic légitime (newsletter, campagne, passage média).
• Un CPU saturé : les requêtes sont traitées plus lentement, donc elles restent plus longtemps en cours et les EP montent.

Le 508 est souvent le symptôme d’un autre goulot. Soigner le symptôme sans trouver la métrique saturée ne sert à rien.

1. Confirmer quelle limite est atteinte

Ouvrez cPanel → Metrics → Resource Usage (parfois nommé « CPU and Concurrent Connection Usage »). Repérez la métrique qui touche 100 % au moment de l’erreur. Les EP sont la cause la plus fréquente, la mémoire vient surtout des extensions lourdes et des boutiques WooCommerce (source : HostMedia, base de connaissances).

La règle de lecture est simple. Si la courbe EP colle au plafond pendant un 508 ou un 503, le blocage vient bien des EP. Si elle reste plate, regardez le CPU, la mémoire et l’I/O (source : AHosting, 2026).

Attention à la mémoire : la directive PHP memory_limit et la limite mémoire du compte sont deux plafonds distincts. Relever la première ne lève pas la seconde, et ne change rien à un problème d’EP. Pour la directive PHP, voyez mémoire PHP épuisée sur WordPress et le guide des directives PHP.

2. Regarder qui visite : robots et requêtes abusives

Dans cPanel → Metrics → Raw Access (ou via les logs d’accès fournis par l’hébergeur), cherchez les adresses IP et les user-agents les plus actifs. Surveillez aussi les URL les plus appelées : wp-login.php, xmlrpc.php, wp-cron.php, admin-ajax.php, les recherches ?s= et les filtres de catalogue.

Si un robot abuse, bloquez son IP ou son user-agent dans le .htaccess, ou limitez le débit au niveau d’un CDN ou d’un pare-feu. Vérifiez avant que Googlebot n’est pas touché : John Mueller recommande de s’assurer qu’un CDN, un WAF ou un limiteur de débit ne le bloque pas (source : Search Engine Journal, 2025). Pour le cas voisin des refus de requêtes, voyez l’erreur 429.

3. Mettre les pages publiques en cache

Chaque requête PHP dynamique non mise en cache occupe un EP pendant toute sa durée : chargement de page, recherche, envoi de formulaire (source : AHosting, 2026). Une page servie depuis le cache n’appelle pas PHP, donc elle ne consomme pas d’EP.

• Activez un cache de pages (comparatif : meilleurs plugins de cache WordPress).
• Sur WooCommerce, excluez le panier, la commande et le compte client du cache.
• Pour les pages qui ne peuvent pas être cachées, un cache objet allège la base de données : voir Redis sur WordPress.

4. Remplacer WP-Cron par un vrai cron

WP-Cron est le pseudo-cron de WordPress : il se déclenche à chaque visite au lieu de suivre l’horloge du serveur. Il gère les publications programmées, les vérifications de mises à jour et les tâches de nombreux plugins. Sur un mutualisé saturé, chaque page vue lance un appel interne à wp-cron.php, ce qui peut produire des erreurs ou des timeouts pendant les pics (source : Astuces WP, 2026).

La procédure :

1. Dans wp-config.php, avant la ligne « That’s all, stop editing », ajoutez :

   define( 'DISABLE_WP_CRON', true );

2. Dans cPanel → Cron Jobs, créez une tâche toutes les 5 minutes :

   */5 * * * * wget -q -O - "https://votre-domaine.fr/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

3. Ne supprimez pas wp-cron.php : le fichier reste nécessaire, c’est le cron système qui l’appelle (source : Sécurité WP, 2026). WP Rocket recommande la même démarche (documentation WP Rocket).

Espacez aussi les tâches lourdes (sauvegardes, imports, envois de newsletters) pour qu’elles ne tournent pas en même temps.

5. Auditer les extensions gourmandes

Installez Query Monitor et repérez les extensions qui multiplient les requêtes SQL ou les appels externes : la méthode est détaillée dans trouver le plugin qui ralentit WordPress. Désactivez les suspects un par un (sauvegarde, sitemap, recherche, statistiques, import) et regardez la courbe EP dans Resource Usage après chaque test. Pour un diagnostic plus large, le guide du site WordPress lent complète cette étape.

6. Protéger le référencement pendant la crise

Quand le serveur renvoie beaucoup de 5xx, Google réduit son rythme d’exploration sur tout le nom d’hôte, y compris pour les pages qui répondent correctement. Il le réaugmente automatiquement quand les erreurs diminuent. Le contenu reçu avec un 5xx est ignoré, et une URL en erreur trop longtemps finit par sortir de l’index (source : Google Search Central, 2026).

Si Googlebot lui-même sature le compte, vous pouvez renvoyer volontairement un 503 ou un 429, avec un en-tête Retry-After. Google déconseille de le maintenir plus de 1 à 2 jours, sous peine de voir des URL retirées de l’index (source : Google Search Central, 2026). N’utilisez jamais un 403 ou un 404 pour freiner le crawl. Suivez ensuite les « Statistiques sur l’exploration » de la Search Console. Pour le 503, voyez l’erreur 503 sur WordPress.

Récapitulatif : cause → solution

Quand changer d’offre

Changez d’offre quand le site reste au plafond après le cache, le vrai cron et le nettoyage des extensions, et que le trafic est légitime. C’est aussi le cas d’une boutique dont le panier et la commande ne se cachent pas.

Une offre supérieure accélère le traitement, mais n’élimine pas forcément tous les dépassements occasionnels (source : Serversaurus, 2026). Elle ne remplace donc pas les étapes ci-dessus. Passez d’abord par la case diagnostic, puis comparez : offre supérieure du même hébergeur, ou VPS. Pour une boutique, voyez quel hébergeur pour WooCommerce.

FAQ

Quand passer la main à un pro

Faites-vous aider si les courbes restent au plafond sans cause visible dans les logs, si le 508 revient après chaque correctif, ou si vous ne pouvez pas accéder aux logs, à SSH ou aux crons. Ce suivi (cron, cache, extensions, surveillance des pics) fait partie de ce que couvre une maintenance régulière, qui évite que la saturation vous surprenne un jour de campagne.