A memory-exhausted error means a PHP request reached its configured memory limit. Identify the request and component consuming memory before raising limits, because a larger allowance can mask inefficient code or make account resource pressure worse.
IN THIS ARTICLE
01 Read the specific error
Record the allowed memory, attempted allocation, component path and time. Determine whether it occurs during an image upload, import, backup, page request or background job. A one-time large import and a normal homepage request have different expected workloads.
Check the selected PHP version and current service limits through the appropriate management tools. A WordPress configuration value cannot necessarily override a lower hosting limit.
02 Run a focused investigation
- Reproduce the task once with a smaller input where safe, such as a smaller image or import batch.
- Review recent plugin, theme or custom-code changes related to the failing path.
- Inspect the log and available resource information at the failure time.
- Test the suspected component on staging with representative data.
- Review the component developer's requirements and any documented batching or optimisation controls.
03 Example: interpret the memory numbers before changing a limit
The sanitised error below is illustrative. It records a PHP request that reached a 128 MiB limit while attempting an additional 20 KiB allocation. The final allocation size is not the total memory that the task needed.
Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes)
Component: wp-content/plugins/EXAMPLE-IMPORTER/worker.phpRecord whether the action was a normal page view, image upload or large import. For an importer with supported batching controls, compare a small representative batch with the failing workload on staging. Check the web PHP limit separately from the CLI limit; a terminal report can describe a different interpreter.
Expected result: The report connects the failure to a specific workload and component. Any approved memory increase is bounded and measured, while a runaway loop, oversized input or growing dataset receives a correction that addresses its cause.
Should I only increase PHP memory to fix the error?
For oversized media, prepare a suitable web copy. For imports and background processing, use supported smaller batches. For a code loop or unexpectedly large query, correct the implementation instead of continually increasing memory.
If the workload legitimately needs more memory and the plan supports it, adjust the relevant PHP or WordPress limit through the documented service controls. Record the old value, apply a bounded change and measure the result. Do not use an unlimited setting as a standard production fix.
04 Verify the complete task
Run the intended workload again and confirm completion, not merely disappearance of the first error. Check storage, execution time and other resource limits that may become the next constraint. Review ordinary visitor pages while the heavier task runs.
A request that succeeds with more memory can still be inefficient. Monitor whether the requirement grows with data size and whether the component has a known compatibility or performance problem.
05 When to ask for help
Send the domain, action, input size, error excerpt and current limit information through the approved support channel. Avoid sharing private import files unless required through a secure route.
If a live site repeatedly fails on ordinary requests, stop non-essential heavy jobs and prioritise restoring a stable workload. Do not delete random database rows or disable every plugin based on the final file path alone. A good resolution explains why the memory demand rose and confirms that the selected service resources and application behaviour are appropriate.