Technical

Fatal Error: Maximum Execution Time Exceeded - 6 Fixes (2026)

By Daniel Reyes•October 4, 2026•3 min read

Disclosure: some links on this page are affiliate links. We may earn a commission at no extra cost to you. How we test and rate hosts.

Our top pick for most WordPress sites

Bluehost: free domain, free SSL, 24/7 support, 30-day money-back guarantee.

Check Bluehost Deal →

"Fatal error: Maximum execution time of 30 seconds exceeded" means PHP pulled the plug mid-operation - usually during a plugin/theme/core update or a big import. Two ways out: remove what made it hang (the real fix) or give scripts more runway (the symptom fix). Do them in that order.

Fix 1: Remove the Culprit First

The limit exists to kill runaway scripts. If a plugin legitimately needs 90 seconds, raise the limit - but if it's stuck in a loop, no ceiling fixes it. Find the culprit:

1.Check your admin email - WordPress sends a Recovery Mode link after fatal errors, usually naming the plugin/theme that caused it.
2.If it fired during an update: the item being updated is likely the problem. Deactivate it via wp-admin, or if locked out, rename its folder in wp-content/plugins via FTP.
3.No obvious suspect? Deactivate all plugins, run the operation, reactivate one by one until it dies again.

Fix 2: Raise the Limit via wp-config.php

Add this to wp-config.php (above "That's all, stop editing!"):

set_time_limit(300);

300 seconds is generous but sane. Note: set_time_limit() restarts the counter - it gives each script a fresh 300s, not 300 total.

Fix 3: Raise via .htaccess (Apache Only)

php_value max_execution_time 300

Add at the end of .htaccess in your WordPress root. If the site throws a 500 error after this, your host runs PHP as CGI/FPM and forbids .htaccess PHP overrides - delete the line immediately and use another method.

Fix 4: php.ini / user.ini

If your host allows per-account php.ini:

max_execution_time = 300

Check current value first via a phpinfo() file or your host's control panel - some panels (cPanel > MultiPHP INI Editor) expose it directly.

Fix 5: The Shared Hosting Wall

On many shared hosts, max_execution_time is enforced at the server level - your .htaccess/php.ini values are ignored or capped. If nothing changes the limit, that's your answer. Ask support to raise it, or accept that the operation needs splitting (import in chunks, update items one at a time) rather than one long script.

Also check the web server timeout: even if PHP allows 300s, Apache/nginx may kill the request at 60-120s first. The lowest limit in the chain wins.

Fix 6: Prevention

VUpdate plugins one at a time, not bulk - bulk updates chain operations into one long script
VSplit large imports/exports into chunks instead of one monolithic job
VKeep PHP current - newer versions execute faster, finishing within the limit naturally
VWatch for plugins doing unbounded database queries - the slow query log names them

Tight Timeouts Cause This

Shared hosts with aggressive kill scripts create most max_execution_time failures. Bluehost's limits are workable for standard WordPress operations, and 24/7 support can check server-side caps you can't see. From $3.99/mo.

Get Reliable Hosting

Find Your Perfect Hosting Plan

What are you building?

Tell us about your project so we can match the perfect hosting plan.

Question 1 of 425% complete

Interactive Tool

Hosting Cost Calculator

See exactly how much you'll spend on hosting over time. Compare Bluehost vs popular alternatives and discover your potential savings.

Time Period: 3 years

Monthly Revenue: $0

Used to calculate transaction fees (Shopify charges 2% on sales)

Compare Against:

Bluehost Plan:

Shopify Basic (3yr)

$1,044

Bluehost (3yr)

$444

You Save

$600

58% less than Shopify Basic

Save $600 with Bluehost →

Frequently Asked Questions

What does 'Maximum execution time of 30 seconds exceeded' mean?

PHP killed a script that ran longer than the server's allowed limit (usually 30-60 seconds). It typically fires during plugin/theme/core updates, imports, or heavy operations - the process didn't finish before the timer ran out.

What's the fastest fix for max_execution_time?

Identify and remove the item that caused it - usually a recently installed plugin or theme. Then, if the operation is legitimately heavy (large import, big update), raise the limit: add php_value max_execution_time 300 to .htaccess, or set_time_limit(300) in wp-config.php.

How do I increase max_execution_time in .htaccess?

Add 'php_value max_execution_time 300' at the end of your .htaccess file (in the WordPress root). Works on Apache hosts that allow PHP overrides - if it throws a 500 error, your host doesn't allow it; use the wp-config or host-panel method instead.

Why doesn't increasing the limit help?

On shared hosting the limit is often enforced server-side and can't be overridden from .htaccess or php.ini - only the host can change it. Also, a limit is a symptom-killer: if a plugin is stuck in a loop, no limit fixes it. Fix the script first.

How do I find which plugin caused the error?

WordPress emails the admin a Recovery Mode link naming the culprit after a fatal error. Otherwise: deactivate all plugins, run the operation, reactivate one by one until it recurs. The plugin that makes the error return is your culprit.

Is a higher max_execution_time bad for security?

Slightly - the limit exists partly to stop runaway scripts eating resources. 300s for a site that does heavy imports is reasonable; 0 (unlimited) is not. Keep it tight, and prefer fixing slow queries/scripts over raising ceilings.

Ready to launch?

Get Bluehost from $3.99/month with a free domain, free SSL, and 30-day money-back guarantee.

Start for $3.99 →