Maximum Execution Time Exceeded WordPress: How to Fix It

You clicked "Update," stepped away for a minute, and came back to a white screen and one cold line of text: Fatal error: Maximum execution time of 30 seconds exceeded. Your dashboard is gone. Maybe the front end too. Breathe. Your site isn't broken, and you almost certainly haven't lost a thing.

This guide explains exactly what the maximum execution time exceeded WordPress error means, why it happens, and how to clear it in a few minutes — then how to stop it from ambushing you mid-import next week.

Quick Answer: The error means a PHP script ran longer than your server's time limit (often 30 seconds), so PHP killed it to protect the machine. Fix it by raising max_execution_time to 120–300 seconds in wp-config.php, .htaccess, or php.ini — then find the slow plugin or task that triggered it. If it keeps returning, your hosting plan is the real bottleneck.

What This Error Actually Means

PHP runs WordPress, and PHP keeps a stopwatch on every script — and a host like Hostaccent sets that stopwatch to a sane default, while a cut-price shared plan often caps it at just 30 seconds. The setting is called max_execution_time, measured in seconds. The moment a script runs longer than the limit, PHP stops it dead and throws the fatal error you're staring at.

Why have a limit at all? Without one, a single stuck script could hog the CPU forever and drag down every other site on the server. That ceiling is plenty for loading a page. It is not always enough for a plugin update, a 200MB media import, or a full backup.

Here's the reassuring part: this is a limit error, not a corruption error. Nothing in your database broke. The operation simply got cut off partway. Reload, and the dashboard is usually back. The fix is about giving the heavy task more room — or making the task lighter.

Pro Tip: Note the exact number in the message — "30 seconds," "60 seconds," "120 seconds." That tells you the current ceiling, which tells you how much you need to raise it. If it already reads 300 seconds and still fails, the problem isn't the limit — it's a runaway script or a starved server.

What Causes the Maximum Execution Time Exceeded WordPress Error

In the support tickets our team at Hostaccent handles, this exact error clusters around a handful of triggers. Ranked by how often we actually see them:

1. A low host-imposed PHP limit. The single most common cause. Budget shared plans ship with max_execution_time at 30 seconds. Any slightly heavy task trips it.
2. A heavy plugin doing real work. Backup plugins, migration tools, page builders, and import/export tools routinely run for a minute or more. On a 30-second ceiling, they fail every time.
3. Large imports. WooCommerce product CSVs, demo-content imports, and media-library uploads are classic offenders — thousands of rows or files processed in one request.
4. A starved server. On an oversold shared box, the script isn't just long, it's slow, because the CPU is busy serving everyone else. Raising the limit only delays the failure.
5. A slow external API call. A plugin waiting on a sluggish third-party service (a license check, a remote feed) can stall until the clock runs out.
6. Inefficient or buggy code. A poorly written plugin or an accidental loop can run far longer than it should. Rare, but it happens.

Notice the pattern: causes 1 through 3 are fixed by raising the limit. Cause 4 is fixed by better hosting. Causes 5 and 6 need you to find the specific culprit. Work in that order. If you want the exact mechanics, the official manual page for PHP's execution-time function is worth a two-minute skim.

How to Fix It, Step by Step

Start with the fastest fix and stop the moment the error clears. Most people are done after Step 1.

Step 1: Raise the limit in wp-config.php

Open wp-config.php in your site's root folder using your file manager, cPanel, or SFTP. Just above the line that reads /* That's all, stop editing! */, add:

phpCopy
set_time_limit(300);

That gives scripts 300 seconds (5 minutes). Save, then retry the operation that failed. Clean, reversible, no special server access needed.

Insider Insight: Always edit a copy first, or write down the line you added. When we migrate WordPress sites, the single most common self-inflicted wound we see is a stray character pasted into wp-config.php that takes the whole site down. One misplaced quote breaks everything. Back the file up before you touch it.

Step 2: Use .htaccess (Apache servers)

If your host runs Apache — most cPanel hosts do — set the limit in the .htaccess file in your site root. Add this line:

bashCopy
php_value max_execution_time 300

Save and retry. If you get a 500 error instead, your host has locked php_value overrides; remove the line and move to Step 3. The official Apache .htaccess guide explains when overrides are allowed.

Step 3: Edit php.ini or .user.ini

This is the cleanest fix because it changes the limit at the source. Find or create php.ini (or .user.ini on many shared hosts) and set:

bashCopy
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

I added memory_limit on purpose. Time-limit failures and memory failures travel together — a big import often needs both. The PHP configuration reference lists every directive if you want to tune further.

Step 4: Use your control panel (no code)

If editing files makes you nervous, most panels expose these settings directly. In cPanel, open MultiPHP INI Editor, pick your domain, and raise max_execution_time and memory_limit with simple fields. No file editing, instantly applied. On our own stack at Hostaccent, this is the route we point most customers to first — it's the hardest one to get wrong.

Step 5: Find the plugin that's actually slow

Raising the limit treats the symptom. If a single plugin needs 200 seconds to do a routine job, that's worth investigating. Deactivate all plugins, retry the task, then reactivate them one at a time until the error returns. The last one you switched on is your culprit.

Once you know which plugin it is, decide: does it genuinely need that long (a real backup of a large site), or is it just inefficient? If it's the latter, a leaner alternative will save you grief. Our walkthrough on diagnosing a slow WordPress site covers how to isolate a heavy plugin properly.

Step 6: Move the heavy job off the web request

Some tasks shouldn't run through a browser at all. A 50,000-row product import or a full-site backup belongs in WP-CLI or a server cron job, where the web time limit doesn't apply. If you import constantly, this is the durable fix — not an ever-rising timeout.

How to Confirm the Fix and Stop It Recurring

After you change a setting, confirm it actually took. In WordPress, go to Tools → Site Health → Info → Server and check the reported max_execution_time. If it still shows 30, your edit didn't apply — the host may override it, and you'll need the control panel or a support ticket. (WordPress documents the Site Health screen if you've never opened it.)

Then re-run the exact task that failed. If it completes, you're done.

To stop repeats:

• Keep your plugin count lean. Across the sites we host, the dashboards that throw this error most are the ones running three overlapping backup or optimization plugins at once.
• Run PHP 8.1 or newer. Modern PHP is meaningfully faster than 7.4 — the same import that times out on old PHP often finishes comfortably on 8.3.
• Schedule big jobs for off-peak hours, when the server has headroom.
• Watch your memory too. If you also see "Allowed memory size exhausted," raise memory_limit to 256M or 512M alongside the time limit. Our guide on fixing high TTFB in WordPress digs into the server-side timing behind both.

Pro Tip: If you raise the limit to 300 seconds and the task still dies — or you get a 504 Gateway Timeout instead — the bottleneck has moved upstream to your web server or PHP-FPM, not PHP's script timer. That's a different fight; our 504 Gateway Timeout fix covers it.

When the Fix Is Better Hosting, Not a Bigger Number

Here's the honest part most tutorials skip. Sometimes raising max_execution_time doesn't fix anything — it just buys you a slower failure. That's the tell-tale sign of an oversold server.

On our Nginx → Apache stack with NVMe SSD storage, the operations that time out on cramped shared plans — imports, backups, bulk edits — usually finish in a fraction of the time, because the CPU and disk aren't being shared with hundreds of noisy neighbours. The script isn't faster because we raised a number. It's faster because it isn't waiting in line.

When we migrate customer sites off budget shared hosting, we repeatedly see the same story: the timeout errors vanish on their own, before anyone touches a single PHP setting. If you've already raised the limit to 300 seconds and still hit the wall, no config edit will save you. You've outgrown the plan. A setup with isolated resources — a VPS or cloud plan built for high-traffic WordPress — is the actual fix.

Key Takeaways

Let's pull it together. Clearing the maximum execution time exceeded WordPress error comes down to five things:

• Raise the limit first. Set max_execution_time to 300 seconds in wp-config.php, .htaccess, php.ini, or your control panel.
• Add memory if needed. Bump memory_limit to 256M when imports are involved — time and memory limits fail together.
• Find the slow plugin. Deactivate, test, reactivate one by one. Replace anything that's needlessly heavy.
• Move big jobs off the browser. Use WP-CLI or cron for large imports and backups.
• Upgrade the host if the limit doesn't help. A bigger number can't fix a starved server. (Our 30-minute slow-site diagnosis helps you tell the two apart.)

A Faster Path If You'd Rather Not Babysit PHP Limits

If you'd rather not tune PHP settings every time a plugin update or import stalls, the cleaner answer is hosting that gives your site its own resources. Hostaccent's Linux VPS plans start at $7.99/mo for the Basic plan, with isolated CPU and RAM, NVMe SSD storage, sensible default PHP limits, and UK-based human support — from a company that's UK-registered and hosting sites worldwide.

It's not magic — a VPS still has finite resources, and a genuinely huge import can need tuning anywhere. But on isolated hardware, the routine tasks that trip a 30-second shared limit simply don't, and you stop firefighting the same error. As of 2026, that's the most reliable way off the timeout treadmill for a growing site.

Frequently Asked Questions

What does the maximum execution time exceeded WordPress error mean?

It means a PHP script ran longer than your server's time limit — often 30 seconds — so PHP stopped it to protect the server. It's a limit, not corruption. Your database is fine; the task just got cut off. Raising max_execution_time and retrying usually clears it.

How do I increase max_execution_time in WordPress?

Add set_time_limit(300); to wp-config.php, or php_value max_execution_time 300 to .htaccess on Apache, or set max_execution_time = 300 in php.ini. The no-code route is your host's control panel — in cPanel, the MultiPHP INI Editor. Confirm it under Tools → Site Health → Info → Server.

Is it safe to set max_execution_time very high?

Raising it to 120–300 seconds is safe and common. Setting it to thousands of seconds is risky — a genuinely stuck script could tie up server resources for ages. If 300 seconds isn't enough for a normal task, the real issue is an inefficient plugin or an underpowered server, not the limit itself.

Why does the error come back after I increase the limit?

Usually because the server is oversold and the script is slow, not just long — so it crawls past even a raised limit. A heavy or buggy plugin can also be the cause. If a higher limit only delays the failure, that's a strong sign you need isolated resources rather than another config tweak.

Does this error mean my WordPress site is broken?

No. It's a fatal runtime error for one script, not damage to your site. The page that ran out of time stops, but your content, database, and files stay intact. Reload the dashboard and it's typically back. Fix the underlying limit or task, and the error stops.

Can a slow host cause maximum execution time exceeded errors?

Yes — it's one of the most common reasons. On an overcrowded shared server, scripts run slowly because CPU and disk are shared with too many sites, so they hit the limit even on routine jobs. Moving to a plan with dedicated resources, like the isolated NVMe setups Hostaccent runs, usually makes these timeouts disappear.