Your online store keeps going down

Almost every store owner discovers an outage the same way: an email that says the site is not working. That is late, unverifiable and usually missing the detail that matters. Uptime monitoring costs a few dollars a month and changes the conversation entirely. Monitor two URLs, not one. The homepage is often cached at the edge and can answer perfectly while the backend is dead, so also monitor something on the buying path — a category, a product, or the cart — which forces a real request through PHP and the database. Then make sure the alert reaches a human being, on a channel that person actually reads at nine in the evening. Finally, keep the incident log, because a single outage is an anecdote and eight timestamped ones are a pattern that points straight at the cause.

• Monitor the homepage and one checkout-path URL separately
• Check every minute, not every fifteen, or you will miss the short ones
• Route alerts to a phone, not to a shared inbox nobody watches
• Keep a dated log of every incident, its duration and its error code

What a broken store shows the visitor is diagnostic information, so capture it before you restart anything. A 502 or 503 with a fast response means the web server is alive but nothing behind it could take the request, which points at exhausted PHP capacity. A request that hangs and eventually times out points at something blocking downstream, usually the database or an external API called during page render. A message about a database connection means connections were refused, not that data is lost. A blank white page is a PHP fatal error or an exhausted memory limit, and it is written down in the error log. A browser security warning is a certificate, not a server. A page that will not resolve at all for some people and works for you is DNS. Five seconds of screenshotting saves an afternoon of guessing.

Most WooCommerce outages under load are not the server dying, they are the queue in front of it filling up. PHP serves your site with a fixed number of workers, and every uncached request occupies one until it finishes: a logged-in session, an add-to-cart, a checkout step, a search, an admin screen. If your plan allows ten workers and the average request takes two seconds, you can serve roughly five requests per second before arrivals start waiting, and once the queue overflows the host answers 502 or 503 until it drains. The signature is that outages track traffic: a newsletter send, an ad day-part, a crawler sweep. Ask your host for worker count and queue wait time, not just CPU graphs. Caching anonymous pages and cutting time per request buys headroom cheaply, which is why speed work often ends the crashes on its own.

A WooCommerce database that has run for years without maintenance gains weight in predictable places: post revisions, expired transients that were never cleaned up, orphaned metadata from plugins you removed, log and session tables, and an options table full of autoloaded rows read on every single request. The symptom is rarely a clean outage. The store gets slower under ordinary traffic until queries stack up and connections are refused, which is the moment the database error appears. Memory limits fail differently and more abruptly: PHP hits its ceiling mid-request and returns a blank or half-rendered page, usually on the same heavy screen each time, such as a large category, a report, or a bulk action in admin. Both are measurable before they are expensive. Look at autoloaded option size and the slow query log before you buy a bigger plan.

Look at the clock on your incidents before you look at the code. WordPress cron is not a real scheduler; it fires on visitor requests, so a queue of overdue jobs runs on top of live traffic instead of at three in the morning. Add a full backup that reads every file and dumps the database, a product feed export, a plugin rebuilding its search index, an hourly sync with accounting or an ERP, and it becomes entirely normal for a store to fall over at the same minute every day while the server looks idle in between. The tell is regularity: an outage at 12:05 on weekdays is a schedule, not a mystery. The fix is scheduling rather than hardware. Move cron to a real system job, push backups and exports off-peak, and stop anything that reindexes during business hours.

When outages begin within hours of an update, treat that as the leading hypothesis and then prove it rather than assuming it. Two plugins can each be correct on their own and still conflict: a shared library loaded at two versions, a hook that now fires twice, a payment extension calling an endpoint that changed shape. The signature is a fatal error on one template while the rest of the store works, or an admin action that white-screens. WordPress writes fatal errors to the PHP error log with a file path and a line number, and that path names the responsible plugin more reliably than any hunch. There is a structural point underneath this too: the more plugins do rendering work on every page view, the more surface exists to break, which is part of what plugin bloat costs you beyond speed.

• Reproduce on a staging copy before touching the live store
• Read the PHP error log first; it usually names the file
• Disable plugins one at a time via WP-CLI, not by guesswork
• Keep a dated update log so you can correlate incidents later

Three causes look like a server problem and are not. Aggressive crawlers and scrapers, including AI training bots, price monitors and a badly configured feed importer walking every filter combination, can consume your whole worker pool while human traffic stays flat, and the access log shows it within minutes. An expired TLS certificate takes the store offline instantly and completely, with a browser warning rather than an error page, and it usually happens on domains where auto-renewal quietly stopped months earlier. DNS misconfiguration produces the strangest evidence of all: the site works for you and is unreachable for others, because a stale record, a lapsed registration or a half-finished nameserver change propagates unevenly. All three are cheap to rule out, and all three leave evidence your host will ask for anyway, so collect it before you open the ticket.

• Exact timestamps and duration, with your timezone stated
• The failing URL and the status code or screenshot you saw
• Whether it reproduced from another network, device or country
• The matching lines from the access and PHP error logs

Most of what is on this page is a hosting and maintenance problem, and the honest fix is a better host or a maintenance routine rather than a new storefront. If the store runs on a cheap shared plan with a handful of PHP workers and a database nobody has touched in years, moving to managed WooCommerce hosting with object caching and real cron will end the outages for a fraction of a project budget, and an ongoing maintenance arrangement keeps them ended. Do that first. It is also worth being exact about what decoupling changes, because it is easy to oversell. A Next.js storefront renders catalogue pages ahead of time and serves them from a CDN, so category and product pages stay online while WordPress is restarting or saturated. Checkout still depends on WooCommerce being up, because that is where stock, tax and payment live. Decoupling narrows the blast radius; it does not make a store immune, and whether it fits you deserves a real answer first.