Magento 2 “Error Processing Your Request” – Causes & Fix (Logs + Steps)

If your Magento 2 storefront or admin shows “There has been an error processing your request” (often with “Exception printing is disabled by default for security reasons”), it’s not the real error. It’s Magento’s generic safety screen. The actual exception is stored in your log files.

This guide shows the fastest way to find the root cause and fix it, whether you’re on Ubuntu/Debian, CentOS/AlmaLinux, Nginx/Apache, or a local setup like XAMPP/WAMP.

Quick diagnosis (90 seconds)

If you see an Error log record number, open: [Magento Root]/var/report/<record_number>
If there is no record number, check: var/log/exception.log and var/log/system.log
The first meaningful stack trace lines usually point to the cause: a module, class, template override, permission error, or server limit.

What this message actually means

Magento shows this page when an exception happens but detailed output is disabled (common in production mode). The message is a wrapper. The real problem is always inside Magento’s report or log files.

It commonly appears after:

Installing or upgrading a Magento 2 extension or theme
Running deployment steps (setup upgrade, compilation, static content deploy)
Changing templates/layout overrides
Cache or generated code becoming stale after updates
File permissions or ownership issues on writable directories
Server limits (memory, disk space, missing PHP extensions)
Misconfiguration (store URLs, environment config, module settings)

Step 1: Use the Error log record number (fastest method)

If Magento shows a log record number (example: 15415484984314), open the matching report file:

[Magento Root]/var/report/15415484984314

How to do it:

Connect to your server via SSH (or FTP if that’s your only option).
Go to var/report.
Open the file that matches the record number shown on the error page.
Look for:
- the exception message (what failed)
- the module/class/file name (where it failed)
- the first relevant stack trace lines (why it failed)

If you’re in the middle of a deployment and this error appears right after upgrades, this post on Magento troubleshooting and deployment tips can help you avoid repeated downtime in future releases.

Step 2: No record number? Check Magento and server logs

Magento log files to check first:

[Magento Root]/var/log/exception.log
[Magento Root]/var/log/system.log
[Magento Root]/var/log/debug.log (only if enabled)

Also check web server logs:

Nginx error log (commonly: /var/log/nginx/error.log)
Apache error log (commonly: /var/log/apache2/error.log)

If the page shows a 500 error or white screen, the server log often contains the first useful clue, especially for memory exhaustion or PHP fatal errors.

Step 3: Enable developer mode safely (staging/local only)

Developer mode can reveal more detailed stack traces. Use it on staging or local environments. Avoid enabling developer mode on production because it can expose sensitive information.

Enable developer mode:

bin/magento deploy:mode:set developer

If you still need more detail in a safe environment, you can enable error display temporarily by editing: [Magento Root]/app/bootstrap.php

error_reporting(E_ALL);
ini_set('display_errors', 1);
$_SERVER['MAGE_MODE'] = 'developer';

After debugging, revert changes and switch back:

bin/magento deploy:mode:set production

If you work with Hyvä or are planning a performance-focused frontend, you may also want to explore our Magento performance and optimization resources for preventing these failures during releases.

Common fixes once you see the real exception

1) Extension or theme conflict

If the stack trace points to a specific module, the fastest test is to disable it and re-check. This confirms whether the issue is caused by an incompatible extension version, missing dependency, or broken override.

bin/magento module:disable Vendor_Module
bin/magento cache:flush

2) Cache flush and compilation

After upgrades or code deployments, stale generated code can trigger this error. Flush cache and recompile dependency injection:

bin/magento cache:flush
bin/magento setup:di:compile

If you upgraded modules or database schema, run:

bin/magento setup:upgrade

3) File permissions or ownership

If logs mention “permission denied” or Magento cannot write to files, verify that writable directories are writable: var, generated, and pub/static. This is one of the most common causes right after deployment.

4) PHP memory limit or server resource limits

If the logs show memory exhaustion, increase PHP memory (and confirm your disk is not full). These problems frequently appear during compilation, static content deployment, or heavy admin actions.