Blank white page? We reveal what Magento is hiding.

The white screen of death is a completely blank page Magento serves when a PHP Fatal error happens but display_errors is off (the default in production mode). PHP stops, sends no output, and the browser shows nothing. The real error is not gone — it is written to var/log/exception.log, var/report/, or the PHP-FPM error log. The first job is to surface that hidden message; the fix follows from there.

It depends on the cause, billed at a flat $25/hr:

• Quick Fix — $99 (~4h): one well-defined blank page or route with a clear fatal, fixed in 24–48h.
• Bug-Fix Sprint — $499 (~20h): a gnarly root cause (post-deploy WSOD, multiple blank routes, module conflict) plus regression tests.
• Emergency / Retainer: custom, 24/7 on-call with an SLA; a $2,499 stabilization sprint (~100h) is available for high-risk stores.

You get a fixed estimate before any work starts.

Emergencies are triaged within 4 business hours, and most single-cause white screens are back to a working page the same day. Surfacing the hidden fatal usually takes 15–45 minutes once we have access; the fix itself ranges from minutes (regenerate generated/, reset OPcache) to a few hours (isolate a broken module, trace memory exhaustion). We give you a realistic ETA right after we see the error.

We make the hidden fatal visible without exposing it to your customers. On a staging clone we run bin/magento deploy:mode:set developer (or set display_errors = On) so the page shows the real message. In parallel we read var/log/exception.log, var/log/system.log, var/log/debug.log, the newest file in var/report/, and the PHP-FPM / nginx error logs. Between the on-screen fatal and the logs, the cause is almost always obvious within minutes.

Yes. We reproduce the white screen on a staging clone first, fix it there, and only deploy once it is verified. We never turn on display_errors on a live production store where customers could see a stack trace. Every change is reversible — if a deploy misbehaves we roll back in under a minute, so you are never stuck on a dead page.

Post-deploy white screens are usually one of: (1) missing generated/ code — setup:di:compile did not run or failed, so classes like …\Interceptor or …\Proxy do not exist; (2) stale OPcache still serving old bytecode against new files; (3) wrong ownership on var/, generated/, or pub/static so PHP-FPM cannot write. We check the deploy log, regenerate code cleanly, reset OPcache, and fix permissions for your stack.

PHP Fatal error: Allowed memory size of N bytes exhausted means a page blew past PHP’s memory_limit and died blank. Raising the limit alone is a band-aid — we trace why it ran out: an unbounded collection load, a runaway loop, a heavy import, or a leaky third-party block. We fix the offending code path so the page stays under a sane limit, then set memory_limit to a value that fits real traffic.

Yes — this is one of the most common WSOD causes. A freshly installed or version-incompatible module throws an uncaught fatal during bootstrap, whiting out the whole site. We read the log to identify the exact class and module, disable it safely with bin/magento module:disable, get your store back up, then decide whether to patch the module, pin a compatible version, or replace it with a working alternative.

A blank admin (or blank login screen) while the storefront loads usually points to an adminhtml-area fatal: a broken admin module, a corrupt generated/ for the admin area, a session/Redis issue, or an OPcache mismatch. The diagnostic is the same — surface the fatal from var/log and the report file, then fix the specific cause. We also confirm your admin URL and session storage are configured correctly.

We prefer to work on a staging clone so we can safely enable developer mode and reproduce the white screen without exposing errors to customers. If you do not have staging, we can spin up a quick clone or, for genuine emergencies, work carefully on live with display_errors kept off and errors read only from the logs. Either way the live deploy happens only after the fix is verified.

Yes. If PHP-FPM cannot write to var/, generated/, or pub/static — usually from a wrong owner or a too-strict umask after a git pull or scp — Magento fails to bootstrap and the page renders blank. We reset ownership to your web user, apply the correct directory and file modes, and confirm Magento can write its cache, generated code, and static assets. After that the page renders normally.

Yes. Every fix is verified against the real page before we close it, and the same issue is covered by a 7-day fix warranty — if the white screen comes back from the same root cause, we fix it again at no charge. We also hand you a short root-cause note so you (or your host) can avoid the same trigger on the next deploy. For stores that cannot risk repeat downtime, the Emergency / Retainer tier adds 24/7 cover.