WordPress "Maximum Execution Time Exceeded" Error: The Fix

Your product import stalls at 62%, or a plugin update just hangs, and then WordPress throws back: "Fatal error: Maximum execution time of 30 seconds exceeded" in some file buried inside wp-includes or a plugin folder. The process didn't crash from lack of memory this time — it simply ran out of time. Here's what's actually going on and how to fix it without leaving PHP running forever.

What This Error Actually Means

PHP has a setting called max_execution_time that caps how many seconds a single script is allowed to run before the server kills it. It exists so a runaway script — an infinite loop, a hung remote call — doesn't tie up a worker process indefinitely and starve every other visitor on the box. Default values are usually 30 seconds on shared hosting, sometimes 60 on VPS setups.

This is a different limit from memory_limit. A memory error means the script tried to hold too much data in RAM at once. A max execution time error means the script was doing fine, memory-wise, but simply took too long to finish. The fixes overlap in where you go to change them, but the root cause is different, so raising memory won't help here at all.

Symptom: What You'll See

• A white screen or partial page load followed by the exact text: "Fatal error: Maximum execution time of 30 seconds exceeded in ... on line ..."
• It happens on specific, heavy actions — a plugin or theme update, a large media import, a WooCommerce bulk product import, a backup plugin running live, or a report generating on the fly
• The rest of the site works fine; only that one long operation fails
• In server logs you may also see a generic 500 error if the timeout happens at the web server level instead of inside PHP
• Refreshing and retrying sometimes "works" for smaller batches, which is a strong hint the operation is just too big for one request

Common Causes

1. A genuinely long-running task

Importing thousands of products, regenerating thumbnails for a large media library, or running a full-site search-and-replace can legitimately take longer than 30 seconds. This isn't a bug — it's a task that outgrew the default limit.

2. A slow external API call

Plugins that call a payment gateway, a shipping rate API, or a license server during page load will hang if that remote service is slow or unresponsive. PHP waits on the response, the clock keeps running, and eventually the execution limit kills it. This is common with WooCommerce shipping plugins and license-check code that phones home on every page load.

3. A slow or looping database query

A poorly optimized query — especially one running inside a loop, once per item in a bulk operation — can quietly eat most of your time budget before you even notice. This is usually the real cause when the same import worked fine with 50 rows but times out at 5,000.

4. A hard cap set at the server level

Some hosting configurations enforce a maximum ceiling that user-level settings (.htaccess, wp-config.php) cannot override, particularly on tightly managed shared hosting with CloudLinux. If your changes don't seem to take effect at all, this is usually why — check the fix table below for where the real control lives.

How to Fix It

Option 1: Raise it via .htaccess (Apache/LiteSpeed)

Add this near the top of your site's .htaccess file, above the WordPress block:

php_value max_execution_time 300

This works on Apache and LiteSpeed when PHP runs as an Apache module or under suPHP. It has no effect if your account runs PHP-FPM, which is common on modern cPanel and VPS setups.

Option 2: cPanel MultiPHP INI Editor

This is the most reliable route on cPanel hosting and works regardless of how PHP is running:

1. Log in to cPanel and open MultiPHP INI Editor
2. Select your domain from the dropdown
3. Find max_execution_time and set it to 300 (5 minutes is usually enough headroom)
4. Click Apply — no restart needed, it takes effect on the next request

Option 3: wp-config.php for the current request only

If you can't touch server-level PHP settings, you can raise the limit from inside WordPress for a specific operation. Add this near the top of wp-config.php, or directly in a plugin doing the heavy lifting:

set_time_limit(300);

Note that set_time_limit() is disabled on some hosts running in safe mode or with certain security modules, so it's a fallback, not a first choice.

Option 4: Move the task off the web request entirely

For anything that's genuinely heavy — a full product catalog import, a big search-and-replace, media regeneration — the real fix isn't a bigger number, it's running the job somewhere that doesn't have a 30-second clock at all:

• Use WP-CLI over SSH for imports and bulk operations — CLI requests aren't bound by the same execution limit as web requests
• Split large imports into smaller batches (500 rows instead of 5,000) so each request finishes comfortably inside the limit
• Run heavy jobs through a real cron job instead of triggering them from an admin page click

Where to Change It, Depending on Your Setup

When Raising the Limit Isn't the Real Fix

If you keep having to push the number higher — 300 seconds, then 600 — that's a sign something is actually slow, not just big. Before cranking the limit further:

• Install Query Monitor and watch which database query or hook is eating the most time during the failing operation
• Check whether a plugin is making a synchronous remote API call on every item in a loop — batch those calls instead
• Look at slow query logs in MySQL if the timeout correlates with a specific bulk action
• Confirm the task isn't something that should be a background cron job in the first place

Prevention

• Set a sane default (120-300 seconds) for the domain up front if you regularly run imports or bulk plugin actions, rather than firefighting it live
• Use WP-CLI for anything bulk — imports, migrations, search-and-replace — instead of triggering it through wp-admin
• Keep an eye on plugins that make external API calls on page load; move them to cached or async calls where possible
• Batch large data operations instead of running them as one giant request