If WooCommerce keeps crashing, the cause is almost always one of a short list: an exhausted memory limit, too few PHP workers, a plugin conflict, a PHP version mismatch, a database error, bot traffic, a flood of background jobs, a full disk, or a host that cannot carry the store. Start with the error log, because it names the cause far faster than guessing does.
This checklist is for store owners, agencies and developers who are tired of WooCommerce site down alerts. It walks through the causes in the order most worth checking, shows what each looks like, and ends with how to tell when the problem is your hosting and not your store. As of October 2026, every fix below uses documented WordPress or WooCommerce settings.
When WooCommerce keeps crashing, match the symptom first
A white page, a 500 error and a 504 timeout are different problems, even though customers describe all three as “the site is broken.” Use the table to pick where to look first.
| Symptom | Likely cause | First fix |
|---|---|---|
| WooCommerce white screen, no message | PHP fatal error, often memory | Read the PHP error log, then raise the memory limit |
| WooCommerce 500 error after an update | Plugin or theme conflict, PHP mismatch | Disable plugins by renaming the folder, check PHP version |
| 503 during sales or campaigns | PHP workers saturated | Check worker count and slow requests, add capacity |
| 504 on checkout or admin | Slow query or long request past a timeout | Find the slow plugin or query, raise the time limit briefly |
| “Error establishing a database connection” | Database down, wrong credentials, overloaded MySQL | Test credentials, check MySQL status and disk space |
| Site slows, then dies at night | Bots, cron or Action Scheduler backlog | Check access logs and pending scheduled actions |
| Everything fails at once, uploads break | Disk full | Check disk usage, clear logs and old backups |
1. Read the error log before you change anything
Guessing wastes hours when WooCommerce keeps crashing. The log usually states the file, the line and the reason for the failure. Check your host’s PHP error log first, which most control panels expose.
If you have no log, WordPress can create one. The WordPress debugging documentation explains that setting WP_DEBUG_LOG saves errors to a debug.log file, usually at wp-content/debug.log, and that setting WP_DEBUG_DISPLAY to false keeps errors off the page your customers see.
The same page says debug tools are not recommended on live sites and are meant for local testing and staging. Copy the store to staging when you can. If you must log on live, enable it briefly, capture the error, then switch it off and remove the file. WooCommerce also keeps its own logs under WooCommerce, Status, Logs.
2. WooCommerce memory limit exhausted
This is the classic cause of a WooCommerce white screen. If WooCommerce keeps crashing on heavy admin pages, suspect it first. WordPress itself only tries to raise PHP memory to 40 MB on a single site by default, according to the WordPress wp-config documentation. A store with payment, shipping and email plugins can pass that quickly.
The WooCommerce guide to the memory limit recommends at least 256 MB and shows the line to add above the “stop editing” comment in wp-config.php: define( ‘WP_MEMORY_LIMIT’, ‘256M’ ). It also warns that the WordPress memory limit is separate from the server’s PHP memory limit, so you may need to raise both.
A log entry reading “Allowed memory size exhausted” confirms this cause. If raising the WooCommerce memory limit only delays the crash, a plugin is leaking memory or a large import is running. Fix that source rather than raising the limit again and again.
3. PHP worker saturation, 503 and 504 errors
A PHP worker handles one uncached request at a time. Carts, checkout and logged-in pages cannot be page cached, so they all need a worker. When every worker is busy, new requests queue and then fail.
MDN describes a 503 Service Unavailable response as a server that is not ready to handle the request, with overload from memory, CPU or connection limits as a common cause. A 504 Gateway Timeout means a proxy did not get a response from the upstream server in time.
When WooCommerce keeps crashing under load, both usually trace back to slow requests holding workers. Find the slow ones: heavy reports, uncached search, a payment API that hangs. Then check how many workers your plan really gives you. Our guide to why WooCommerce is slow covers the slow request side in more detail.
4. Plugin conflicts: test on staging, then disable
If WooCommerce keeps crashing after every update, or a WooCommerce 500 error appears right after one, treat it as a conflict. Do not test on the live store. Clone it to staging, then switch plugins off in groups and reload the failing page after each group.
If the admin is unreachable, rename the plugins folder over FTP or SSH, which disables every plugin at once. Rename it back, then rename individual plugin folders to find the culprit. Switch to a default theme next. Update or replace the guilty plugin.
A host with staging that can publish selected changes back, which our WooCommerce hosting includes, makes this routine instead of risky.
5. PHP version mismatch
WooCommerce keeps crashing after a PHP change more often than people expect, whether the host upgraded it or you did. An older plugin that works on one version can fatal on another. The reverse also happens: a new plugin may need a newer PHP than your account runs.
The WooCommerce server requirements list PHP 8.3 or greater as of October 2026. Check which version the site runs, compare it to what your plugins support, and change it on staging first. Our WooCommerce hosting requirements guide lists the other versions to match.
Hosts that set PHP per site let you roll back in a minute.
6. Database connection errors
“Error establishing a database connection” means WordPress could not reach MySQL or MariaDB, or could not log in. Common reasons are wrong credentials after a migration, a stopped database service, too many connections, or a full disk.
Check wp-config.php for the database name, user, password and host. Confirm the service is running and that the disk has space. If tables look damaged, WordPress has a repair tool you can turn on with WP_ALLOW_REPAIR. The wp-config documentation warns that it needs no login while enabled, so turn it off as soon as the repair finishes.
A store database also grows and fragments over time. Old sessions, transients and logs add up, and an object cache reduces the query load.
7. Traffic spikes and bots
Not every visitor is a customer. Scrapers, credential stuffing and card testing bots hit login, cart and checkout pages, which are the expensive ones. A WooCommerce site down at peak hours can look fine in analytics because bots took every worker.
Open the access log and sort by IP and path. Look for hundreds of requests to wp-login.php, xmlrpc.php, add-to-cart URLs or the search page. Block abusive IP ranges, add rate limits, and put a web application firewall in front of the store.
Real spikes need a different answer. Tell your host before a promotion, load test with a free tool, and move to a plan that reserves workers for checkout. Our managed WooCommerce hosting guide explains what to ask for.
8. WP-Cron and Action Scheduler floods
WooCommerce runs background jobs through Action Scheduler: emails, webhooks, order cleanup, and for subscription stores, renewals. By default WordPress starts WP-Cron on page loads. The WordPress cron documentation says it runs on each page load, which adds overhead on busy sites.
If WooCommerce keeps crashing at night, a backlog of thousands of pending actions can saturate workers all by itself. Action Scheduler’s performance guide lists conservative defaults, including 25 actions per batch, a 30 second request limit and one concurrent batch, and calls WP-CLI the best way to process queues faster.
The fix is a real system cron. Set DISABLE_WP_CRON to true in wp-config.php and have the server call wp-cron.php on a schedule, or run Action Scheduler through WP-CLI. Then clear failed or stuck actions and find out which plugin keeps creating them.
9. Disk full
If WooCommerce keeps crashing with no clear error, check the disk. A full disk breaks things in odd ways. Uploads fail, the database stops writing, sessions disappear and PHP cannot write its logs, so the site gives you no clear error at all.
Check disk and inode usage first. Usual offenders are an oversized debug.log, old plugin backups stored inside the site, thousands of image sizes, and error logs that were never rotated. Move backups off the server. Our backup and disaster recovery service keeps copies away from the web server for this reason.
Set an alert at 80 percent usage.
10. When WooCommerce keeps crashing: spotting WooCommerce hosting problems
Sometimes the store is healthy and the platform is not. Signs of WooCommerce hosting problems include crashes at the same time of day on every site on the server, no access to logs, a worker or process limit you cannot see, and support that answers every outage with “clear your cache.”
Ask the host three questions in writing: how many PHP workers does my plan have, what is the memory limit per process, and how long do backups last? If you get vague answers or “unlimited,” plan an exit. Shared plans packed with many accounts are a common reason stores go down during peak hours.
Moving does not have to risk orders. We migrate stores for free, and a person does the work, so you can test checkout on the new server before DNS changes. See our website transfer page or contact us and we will look at your logs with you.
A checklist for when WooCommerce keeps crashing
- Open the PHP error log and read the last fatal error
- Check memory limit, PHP version and disk space
- Look at worker usage and slow requests
- Check the access log for bots
- Check the Action Scheduler queue for a backlog
- Disable plugins on staging, not live
- Take a backup before every fix
Frequently asked questions
Why does my WooCommerce site keep crashing?
When WooCommerce keeps crashing, the most common causes are an exhausted memory limit, saturated PHP workers, a plugin conflict and a full disk. The error log shows which one applies, so read it before you change settings.
How do I fix a WooCommerce 500 error?
Read the PHP error log, then disable plugins by renaming the plugins folder, and switch to a default theme. If the site returns, add plugins back one at a time. Also check the PHP version against what your plugins support.
How much memory does WooCommerce need?
WooCommerce recommends at least 256 MB of WordPress memory. Set WP_MEMORY_LIMIT in wp-config.php, and check that the server’s PHP memory limit is at least as high.
What causes a 503 or 504 error on a WooCommerce store?
A 503 usually means the server is overloaded, for example when every PHP worker is busy. A 504 means a gateway timed out waiting for a slow response. Both point to slow requests or too little capacity.
Is it my host or my store?
If the same failures hit every site on the server, you cannot see worker or memory limits, or logs are unavailable, suspect WooCommerce hosting problems. If the log names a plugin or a query, suspect the store.
Sources
- WordPress.org, debugging in WordPress
- WordPress.org, editing wp-config.php
- WooCommerce documentation, increasing the WordPress memory limit
- WooCommerce documentation, server requirements
- WordPress.org, hooking WP-Cron into the system task scheduler
- Action Scheduler, performance tuning
- MDN, 503 Service Unavailable and 504 Gateway Timeout
Related reading: WooCommerce subscriptions hosting, WordPress hosting cost and WordPress care plans.