sfw/fix
508 high

508 Loop Detected

The server killed the request because it hit an infinite loop or, on shared hosting, blew past a process/CPU cap.

What you see

508 Loop Detected
The server encountered an infinite loop while processing the request.

What’s actually happening

A page that used to load now returns 508, often after a plugin update or a code change. On cPanel/LiteSpeed hosts the same code may flap between 508 and 500 depending on traffic, since it really means you ran out of allowed processes. The page either hangs for several seconds and then throws the 508, or it returns instantly once the host's entry-process counter is already maxed.

Common causes

  • A plugin or theme calling itself recursively, or two plugins triggering each other's hooks in a cycle (common in WordPress with filters that re-save a post inside save_post).
  • A PHP include/require chain that loops back on itself, or an autoloader resolving a class that pulls in the file that's currently loading.
  • Shared hosting EP (entry process) or CPU limit reached — cPanel/CloudLinux LVE repurposes 508 to mean 'too many concurrent PHP processes for this account'.
  • An infinite redirect handled at the application layer (rare) where the framework re-dispatches the same route instead of returning a 30x.
  • WebDAV requests where the resource references itself through bindings (the literal RFC 5842 meaning).

How to fix it

  1. Pull the latest error log and read the backtraceOn Apache/cPanel check /var/log/httpd/error_log or ~/logs/, on LiteSpeed /usr/local/lsws/logs/error.log. A real recursion logs a PHP fatal like 'Allowed memory size exhausted' or 'Maximum function nesting level reached'. If instead you see 'LVE resources exhausted' or 'mod_lsapi: reached process limit', it's a hosting cap, not your code.
  2. Bisect the plugins/extensionsIf it's WordPress, rename wp-content/plugins to plugins_off via SSH or the file manager, confirm the 508 clears, then move plugins back one at a time. The last one you re-enable before the 508 returns is the culprit. For custom apps, disable the most recently changed module first.
  3. Raise the nesting/memory ceiling only to confirm, not to fixSetting xdebug.max_nesting_level=512 or memory_limit=512M will turn the 508 into a slow request that eventually completes. That confirms recursion — it does not fix it. Find the loop and break it; don't ship with the limit cranked up.
  4. Ask the host to show your concurrent process usageIf logs point to LVE/EP limits, run a tool like the cPanel 'Resource Usage' page or 'lveps -d' if you have access. A site hitting its EP cap under normal traffic needs a bigger plan or PHP-FPM tuning (lower pm.max_children that actually fits RAM), not a code change.

Stop it recurring

Add a guard flag or a static recursion counter around any hook that can re-enter itself, and load-test after plugin updates so you hit the process cap in staging, not production.

Related errors