Memory exhausted
"Allowed memory size exhausted" — WordPress asking for a bigger plate, or a smaller appetite.
The memory fatal is refreshingly literal: building your page needed more RAM than PHP is allowed. The lazy fix raises the allowance. The right fix first asks what's eating so much — because sometimes the plate is fine and the appetite is the disease.
Same-day diagnosis. Flat quote before any fix.
What’s actually happening
PHP gives each page-build a memory budget. When a plugin, theme, or operation blows past it, execution dies mid-thought — a white screen or a fatal naming the exact byte count. The error's fine print helpfully names the file that was eating when the plate emptied, which is more diagnosis than most errors offer.
Two legitimate stories: a genuinely hungry site (WooCommerce plus a builder plus imports on a modest limit) that simply needs the standard, more generous allowance — or a leak, where one component consumes wildly beyond reason, and raising the limit just delays the same crash. Distinguishing them is the actual work; the error message's named file usually starts the answer.
The usual causes, ranked
After twenty-seven years of these calls, the odds are well mapped. Start at the top.
A hungry-but-normal stack on a stingy limit
WooCommerce, builders, and image tools are legitimately memory-heavy; some hosts default PHP limits low. The genuine raise-the-limit case.
One component leaking
A plugin loading enormous datasets, an infinite loop, a broken query pulling everything — appetite beyond any reasonable plate. Raising limits feeds it briefly, then the crash returns.
Heavy one-off operations
Imports, exports, image regeneration — legitimate spikes that exceed the everyday budget. Often better run differently than budgeted for.
The admin-only variant
Front end fine, wp-admin fataling — admin screens load more code, so the budget breaks there first. An early warning worth heeding.
What you can safely try first
Nothing below can make things worse — that’s the selection criterion. Anything riskier belongs in professional hands, on a backup.
- 1
Read the error's named file
The fatal names the file that was allocating when memory ran out — a path with a plugin's name in it is a suspect in plain text. Note it; don't edit anything.
- 2
Note what you were doing
Everyday page views exhausting memory versus a big import doing so are different diseases. The trigger action shapes the whole verdict.
- 3
Check your current limit in Site Health
WordPress's Site Health → Info → Server shows the PHP memory limit. Knowing whether you're on a stingy 128M or a generous 512M frames everything.
Stop and call when…
- Raising the limit 'fixed' it before and the error came back — that's the leak signature
- The fatal names a file and the next step is code-level investigation
- It's happening on a store or under real traffic, where each crash has a price
From there it’s our job: same-day look, flat quote, and the $229 flat repair covers most cases of exactly this.
Single Error Fix — buy it now, skip the hunt.
One error, hunted down and fixed — 500s, white screens, redirect loops, broken pages.
Covers one specific error or broken behavior on one site. Diagnosis, the fix, and a plain-English note on what happened. If we can't fix it, you get a full refund.
Questions we hear a lot.
Can I just raise the memory limit myself?
The wp-config edit is famous and sometimes right — but editing config on a live site has its own hazards, hosts cap what you can grant, and if the true problem is a leak you've just bought a delay. The professional version diagnoses first, then raises deliberately or fixes the eater. Same $229 either way.
How much memory should WordPress have?
Simple sites live happily at 128M; WooCommerce and builder-heavy sites deserve 256M; 512M is generous for almost anything. Needing more than that to survive normal traffic isn't a budget problem — it's a component misbehaving, and that component is the fix.
Why did this start suddenly when nothing changed?
Something changed quietly: an auto-updated plugin got hungrier, the database grew past a threshold, or the host adjusted PHP settings. 'Nothing changed' almost always means 'nothing I changed' — the timeline hunt finds the silent change.
Related symptoms & help
Errors travel in packs. If this one visited, check its friends.
Bigger plate or smaller appetite — diagnosed, then done.
Send the symptom, get a same-day look and a flat quote from the developer who's fixed this exact thing more times than either of us can count.