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.
Diagnosis within one business day (Mon–Fri). 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: a look within one business day, flat quote, and the $149 flat repair covers most cases of exactly this.
Error Fix — buy it now, skip the hunt.
One error message, found and gone: memory limits, stuck updates, failed publishing, upload and SSL errors, broken forms.
A full backup before we touch anything, the fix tested on desktop and phone, and a short note on what broke and why. We start within one business day (Monday–Friday) of payment. Full refund if we can't fix it.
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 $149 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.
- White ScreenWhat the memory fatal looks like with errors hidden.
- 504 TimeoutThe time-budget sibling of the memory budget.
- Plugin RepairWhen the eater needs evicting.
- Speed Up WordPressAppetite management, systematized.
- Website RepairThe whole bench.
- Update FailedUpdate failed
- wp-admin Brokenwp-admin broken
- Access DeniedNot allowed to access
Bigger plate or smaller appetite — diagnosed, then done.
Send the symptom, get a look within one business day and a flat quote from the developer who's fixed this exact thing more times than either of us can count.