What's happening
You're uploading a large plugin, importing a 5,000-product WooCommerce catalog, running a bulk action, or just poking around the admin — and PHP kills the process mid-way:
Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/wp-includes/class-http.php on line 1
PHP enforces a hard ceiling on how long a single script can run. The default is 30 seconds — plenty for a normal page load, but far too short for plugin installs, image imports, or bulk exports. When WordPress fires an internal HTTP request via WP_Http and the remote server stalls, or when you're chewing through a large dataset, you hit that wall fast.
Depending on your server access level, there are four different places to raise that limit. Start with whichever matches your setup.
Quick fix — wp-config.php
Got filesystem access? This is the fastest option. Add one line to wp-config.php before the /* That's all, stop editing! */ comment:
<?php
// Raise execution time to 300 seconds
set_time_limit(300);
/* That's all, stop editing! Happy publishing. */
set_time_limit() resets the countdown each time WordPress boots. No server restart needed — the change takes effect on the next request. Safe mode would block it, but safe mode hasn't been relevant since PHP 5.4.
Retry the action that triggered the error. If it completes cleanly, move on.
Permanent fix — php.ini
The wp-config.php method only affects WordPress. For a server-wide change, go straight to php.ini.
Find the active config file:
php --ini | grep 'Loaded Configuration'
No CLI access? Drop a temporary file in your webroot instead:
<?php phpinfo();
Open it in a browser and search for "Loaded Configuration File".
Once you have the path, find this directive and update it:
max_execution_time = 300
Then restart your PHP handler to apply:
# PHP-FPM:
sudo systemctl restart php8.1-fpm
# Apache with mod_php:
sudo systemctl restart apache2
Fix via .htaccess (Apache only)
On shared hosting without php.ini access, .htaccess can sometimes override PHP directives. Drop this at the top of your WordPress .htaccess:
php_value max_execution_time 300
Most cPanel hosts allow this. If your site throws a 500 error immediately after saving, the host has disabled php_value overrides — remove the line and fall back to the wp-config.php approach.
Fix via Nginx + PHP-FPM
Running Nginx? Forget .htaccess — it does nothing here. Set the limit in two places: your FPM pool config and your Nginx server block.
FPM pool config (usually /etc/php/8.1/fpm/pool.d/www.conf):
request_terminate_timeout = 300
Nginx server block:
fastcgi_read_timeout 300;
Apply both changes together:
sudo systemctl restart php8.1-fpm
sudo systemctl reload nginx
Shared hosting — cPanel / hosting panel
Many shared hosts expose PHP settings directly in the control panel. In cPanel, navigate to Software → Select PHP Version → Options and find max_execution_time. Set it to 120 or 300 and save — no restart required.
Can't find the setting, or your changes won't stick? Your host may enforce a hard cap (commonly 60–120 seconds). Open a support ticket — they can sometimes raise it on request.
WP-CLI one-liner for testing
Need to run a specific WP-CLI command that keeps timing out? Override the limit inline without touching any config files:
WP_CLI_PHP_ARGS='-d max_execution_time=300' wp import content.xml --authors=create
Verify the fix worked
Before retesting the real operation, confirm PHP is actually seeing the new value. Save this as check-timeout.php in your webroot:
<?php
echo ini_get('max_execution_time');
Visit it in a browser. It should print 300 (or whatever value you set). Delete the file immediately after — don't leave diagnostic scripts sitting in production.
Then reproduce the original action — plugin install, content import, bulk update — and confirm it runs to completion.
When the error keeps coming back
Still hitting timeouts after raising the limit? The script itself is the problem. A few common causes:
- Hanging external HTTP requests — WordPress is calling a remote API that isn't responding. The stack trace pointing to
class-http.phpis a strong hint. Test reachability from your server:curl -I https://api.example.com - Slow database queries — Enable
SAVEQUERIESinwp-config.phpand log any query taking over 1 second. WooCommerce sites with 10,000+ products are frequent offenders here. - Imports without batching — WooCommerce and WP All Import both support configurable batch sizes. Drop yours to 20–50 items per batch instead of trying to process 500 at once.
- WP-Cron pileup — If
wp-cron.phpis stacking up requests, disable it and use a real server cron instead. Adddefine('DISABLE_WP_CRON', true);towp-config.php, then schedule:*/15 * * * * curl https://yoursite.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
What value should you use?
300 seconds covers the vast majority of WordPress operations. If a routine task needs more than 5 minutes, that's a design problem — not a timeout problem. Investigate batching, background processing via Action Scheduler, or offloading the work to a queue rather than chasing the timeout ceiling upward indefinitely.