When Redis Goes Down, Why Does Your WordPress Site Go Down With It?

You added Redis to make WordPress faster. Six months later, a routine Redis restart takes the whole site down for two minutes and you learn the ugly truth: most Redis object-cache setups convert a cache failure into a site failure. That is backwards, and it is fixable.

The object cache is not supposed to matter this much

WordPress’s object cache is explicitly non-authoritative: MySQL holds the truth, the cache only remembers answers. Losing it should mean one slow pageload while answers are re-computed. For that to hold in practice, the drop-in — the object-cache.php file that routes every cache call to Redis — has to treat Redis as optional at every single call site. Most drop-ins don’t.

How a blip becomes a white screen

1. Unwrapped exceptions. The Redis client throws on connect timeout; the drop-in lets it bubble; WordPress fatals on the very first cache read of the request — before your theme even loads.
2. WordPress “protects” you into a broken state. Since 5.2, a fatal in a drop-in can trigger recovery mode or silently deactivate the cache. When Redis returns, the cache doesn’t — performance quietly degrades until someone notices weeks later.
3. The stampede after recovery. Every request hammers a cold Redis while also hitting MySQL; under real traffic this second wave can hurt more than the outage.
4. Retry storms during the outage. A drop-in that retries each failed operation adds its timeout to every cache call. A 1-second connect timeout times dozens of cache calls per page equals a site that is technically up and practically unusable.

What graceful degradation actually requires

• Every operation wrapped. Not just connect — every get, set, delete, incr. A failure returns a cache miss, logs once, and moves on. The drop-in must be structurally incapable of throwing.
• A circuit breaker. After N consecutive failures, stop calling Redis entirely for a cooldown window and serve straight from request memory + MySQL. Pages stay fast during the outage. Probe occasionally; close the breaker when Redis answers again.
• A watchdog. A minutely health check that re-installs the drop-in if anything removed it and closes the breaker on recovery — so the system heals without a human.
• Visibility. An event log of disconnects and recoveries, hit ratio and latency you can actually see. “Was Redis down last night?” should be answerable from the dashboard, not by archaeology in server logs.

Test it before your customers do

The test is brutally simple and takes five minutes on staging: redis-cli shutdown while you click around the site. A resilient setup shows slightly slower pages and a warning in its dashboard. A fragile one shows the white screen — better to meet it on staging than in a Monday-morning support ticket. Then restart Redis and confirm the cache comes back by itself, because the second failure mode (cache silently gone forever) is the more expensive one.

Resilient Object Cache was built around exactly this failure model: Redis outages become cache misses, never white screens — circuit breaker, auto-healing watchdog and a live health dashboard included. See Resilient Object Cache →