Your store is throwing a 500 error. We get it back to 200.

A Magento HTTP 500 Internal Server Error almost always means a PHP fatal error somewhere in the request. The real cause is written to var/log/exception.log — the most common ones are an exhausted memory_limit, a broken third-party module throwing Class … does not exist, a bad .htaccess rewrite rule, wrong file permissions on var/ or generated/, or a missing setup:di:compile. We start by reading the last lines of exception.log — that single file usually names the culprit.

A 500 is a fatal PHP error during the request; a 503 Service Unavailable usually means the store is in maintenance mode (var/.maintenance.flag) or the generated/ code is missing/stale right after a deploy. A 503 with “Service Temporarily Unavailable” after deploy is the classic “forgot to run setup:di:compile / setup:static-content:deploy” signature. We confirm which one you have from the status code and the logs before touching anything.

A single, well-defined 500/503 with a clear stack trace is a $99 Quick Fix (~4h @ $25/hr), typically resolved in 24–48 hours. A gnarly intermittent error, a batch of bugs, or a deploy that broke several things is a $499 Bug-Fix Sprint (~20h @ $25/hr) with regression tests. If your store is down right now or you want 24/7 cover, the Emergency / Retainer tier is custom-quoted, with an optional $2,499 stabilization sprint (~100h @ $25/hr). Log triage is free — send us the error first.

For an emergency ticket we start triage within 4 hours and most single-cause 500/503 errors are reproduced, root-caused and patched within 24–48 hours. Speed depends on access — if you can give us the exception.log trace and staging or SSH access up front, we move much faster than if we have to arrange access first.

That’s PHP Fatal error: Allowed memory size of N bytes exhausted — a single PHP request tried to use more RAM than memory_limit allows, so it died with a 500. The lazy fix is to raise memory_limit, but that just hides the leak. We find the hot path — usually an unbounded collection load, a huge product import, or a runaway loop in a plugin — and cap or fix it so the limit isn’t hit again. Magento recommends at least 2G for production and 4G for some CLI tasks.

A 503 immediately after deploy is nearly always one of two things: the store is still in maintenance mode (var/.maintenance.flag wasn’t removed), or the generated/ directory is empty or stale so the autoloader throws Class … does not exist. The fix is a clean setup:di:compile followed by setup:static-content:deploy, then clearing the maintenance flag. We verify the generated classes resolve and watch the logs go quiet before we call it done.

Yes. Wrong ownership or mode on var/, generated/, pub/static or app/etc blocks Magento from writing cache, logs or compiled code — which surfaces as a 500. This is one of the most common post-deploy and post-restore causes. We reset permissions to the Magento-recommended scheme (writable dirs 770/660, code 750/640, correct web-server group) rather than the dangerous chmod -R 777 shortcut, and confirm the web server can write again.

Yes — on Apache, a single invalid directive in .htaccess (or a missing mod_rewrite) returns HTTP 500 Internal Server Error on every URL, and the cause shows up in the Apache error log rather than exception.log. We diff your .htaccess against a clean Magento copy, find the offending RewriteRule or unsupported directive, and fix it. On nginx the equivalent is a broken nginx.conf.sample include — same approach.

Yes. A vendor extension throwing Class … does not exist, a fatal in a plugin/observer, or a bad di.xml after install or upgrade is one of the most common 500 sources. We isolate it with bin/magento module:disable bisection to confirm exactly which module is at fault, then either patch the conflict, pin a working version, or quarantine the module and report it to the vendor — whichever keeps your store up safely.

Yes — that’s the whole point. We reproduce and verify every fix on staging or a maintenance clone first, never by experimenting on production. If there’s no staging environment, we set one up or use a short maintenance window. The fix only goes live once it’s confirmed to return HTTP 200 on the affected URLs and the regression suite (checkout, admin, cron) passes.

To move fast we ideally want: the last lines of var/log/exception.log and system.log (or your nginx/Apache error log), SSH or deploy access, and a staging environment if you have one. If you can only share logs at first, that’s enough for a free triage and a likely root cause. We can arrange least-privilege access — a scoped SSH user and admin role — and remove it once the fix is shipped.

Yes. Upgrade-related 500s are common — a third-party module incompatible with the new version, a leftover generated/ from the old codebase, a PHP version mismatch, or a setup:upgrade / setup:di:compile that didn’t complete. We trace it the same way: read the log, reproduce on staging, isolate the module or step, and fix. If it’s broadly upgrade-related, our Magento upgrade bug-fixing service covers the full post-upgrade stabilization.