Visit Website →
← Back to blog

Fix PHP Max Execution Time Without Server Access for Devs & Admins

October 5, 2026
Fix PHP Max Execution Time Without Server Access for Devs & Admins

If your script is throwing "Maximum execution time exceeded," try set_time_limit(60) or the wp-config.php snippet first since both work without server access. If the error persists, check phpinfo() and your web server's own timeout settings (Apache, NGINX, or IIS), since those can override PHP entirely. When you lack admin access to fix it yourself, contact your host with specifics. Always test changes on staging with a backup in place first.

TL;DR:

  • Adjusting set_time_limit() or ini_set() inside scripts temporarily increases execution time but may fail if the server enforces lower timeouts upstream.
  • Properly locating and editing the correct php.ini, user.ini, or .htaccess file is essential to make lasting changes, requiring server restart and cache clearing.
  • WordPress often inherits host PHP limits, so testing with plugin deactivations or troubleshooting slow cron jobs can help identify causes before server tweaks.
  • For persistent issues, server-level settings like PHP-FPM's request_terminate_timeout usually override script-level increases, calling for background jobs or request batching.
  • When unable to fix timeouts yourself, providing host support with error logs, phpinfo() output, and what you've tried ensures accurate assistance, especially on shared plans.
inSave Hosting
Keep WordPress Running Reliably
InSave Hosting provides performance-focused WordPress hosting with easy management, free migration, staging tools, and managed security features.
Visit InSave Hosting

Table of Contents

Quick fixes you can apply inside your script or WordPress files

The fastest fix lives inside the script itself. Adding set_time_limit(60); near the top of a PHP file resets the countdown to a specified number of seconds from that point forward, and calling it again later in a long-running loop extends the execution time further. The set_time_limit manual notes it restarts the timer at zero each time it runs, and that set_time_limit(0) removes the cap entirely, though that carries its own risks on a shared server.

An alternative is ini_set('max_execution_time', '60');, which behaves similarly but only applies for the remainder of that script's execution.

For WordPress sites, add this near the top of wp-config.php, before the line that says "That's all, stop editing!":

  • ini_set('max_execution_time', '300');
  • set_time_limit(300);

Both approaches are temporary runtime adjustments. They do nothing if your web server enforces a lower timeout upstream of PHP, which is a common reason these fixes appear to fail.

Back up wp-config.php before editing it, and test on a staging copy of the site whenever one is available. Our guide on updating your PHP version safely covers the same staging-first approach for related configuration changes.

Pro Tip: Add a one-line log statement before and after the slow code block to record how long it actually runs, so you can confirm whether your change took effect instead of guessing.

How to find and edit the active php.ini file

Before changing anything server-side, confirm which php.ini file is actually in control. Running phpinfo() in a test script shows a "Loaded Configuration File" entry, along with separate "Local Value" and "Master Value" columns for max_execution_time. The PHP runtime configuration docs explain that the local value reflects any per-script overrides, while the master value is the server default.

Once you've located the right file:

  1. Open the active php.ini and find the max_execution_time line, then set it to a reasonable figure like 60 or 300 seconds rather than 0, since an unlimited setting on a shared or production server can let a single broken script consume resources indefinitely.
  2. Check max_input_time too, since large form submissions or file uploads can fail from input parsing limits even when execution time looks fine.
  3. If you cannot edit the main php.ini, use a .user.ini file in the site's root directory for FastCGI or PHP-FPM setups, or add directives through .htaccess if your server still runs mod_php.

Watch for pitfalls: servers sometimes run multiple PHP versions side by side, so edits to the wrong php.ini have no visible effect. Opcode caches can also serve a stale configuration until the PHP service restarts. After any edit, restart PHP-FPM or the web server, and clear any opcode cache before retesting.

Pro Tip: Keep a plain-text note of exactly which file you edited and its full path, since troubleshooting a second timeout issue later is much faster when you already know where the active configuration lives.

WordPress-specific fixes for timeout errors

WordPress inherits whatever PHP timeout your hosting environment sets, but a few site-level moves help before you touch server configuration. The wp-config.php snippet from the quick fixes section is the safest starting point because it is reversible and does not require she'll access.

Plugins that promise to "increase max execution time" are typically just wrappers that write to .htaccess or .user.ini behind the scenes, so they carry the same risk as a manual edit. Back up the site first, the same way you would for a WooCommerce backup plugin setup, regardless of which method edits the file.

To find what's actually causing the slow request:

  • Use the Health Check & Troubleshooting plugin to disable themes and plugins one at a time and reproduce the timeout.
  • Run wp plugin list --status=active through WP-CLI to see what's running, then deactivate suspects individually.
  • Check whether WP-Cron jobs are piling up, since a stalled cron task can masquerade as a general timeout.

Migrations and major plugin updates sometimes need a temporarily higher limit; raise it, finish the task, then revert.

Advanced fixes: PHP-FPM and background job alternatives

When requests still die despite a generous max_execution_time, PHP-FPM's request_terminate_timeout is often the real culprit. The PHP-FPM configuration manual describes it as a hard limit that kills the worker process outright, overriding anything set in PHP itself. Treat it as a last-resort safeguard, not a first fix.

PHP script and PHP-FPM timeout layers

Command-line PHP behaves differently from a web request: the runtime configuration docs note that CLI defaults max_execution_time to 0, meaning no limit at all. That's why long-running imports, exports, or report generation belong in a cron job or CLI script rather than a browser-triggered request.

For genuinely long tasks, consider:

  • Queueing systems like Redis or RabbitMQ to hand off work to a background worker instead of holding a web request open.
  • Breaking a large job into smaller batches processed over several requests or cron runs.
  • Moving scheduled or bulk operations to CLI entirely, bypassing web-request timeouts altogether.

Raising timeouts broadly on a shared server risks tying up worker processes other sites depend on, so scope any increase narrowly to the script that needs it.

Tests and checks to verify the active timeout

Confirm a fix with a short test script rather than trusting that an edit "should" have worked.

  1. Write a file containing sleep(65); echo "done"; and request it directly. If it dies before 65 seconds with a fatal error, something is still capping execution below your intended value.
  2. Add echo ini_get('max_execution_time'); near the top of that same script to see the effective value PHP is using at runtime, per the set_time_limit documentation.
  3. Check web server directives directly: Apache's Timeout setting, NGINX's proxy_read_timeout and send_timeout, or IIS's CGI timeout. WordPress's performance documentation points out that a high PHP limit is pointless if a lower server timeout cuts the connection first.

**A script that times out at 30 seconds despite max_execution_time set to 300 usually points to a server-level timeout, not a PHP misconfiguration, according to the PHP runtime configuration manual.

Check your PHP and web server error logs for the exact timestamp of the failure, since a server-level timeout and a PHP fatal error often log differently and that distinction tells you which layer to fix.

Tests and checks to verify the active timeout — overview diagram

What to send hosting support when you can't change settings yourself

Shared hosting plans usually limit how much of php.ini or server configuration you can touch, while managed or VPS plans give you direct control. If you're stuck on the former, send your host everything they need in one message:

  • Your phpinfo() output or at least the "Loaded Configuration File" path.
  • The exact error text and a timestamp from when it occurred.
  • The affected URL or file path and a list of fixes you've already tried.
  • A request to check php.ini, restart PHP workers, verify request_terminate_timeout, and confirm web server timeout values, with an estimated turnaround.

If support can't adjust these settings at all, that's a sign your current plan has hit its ceiling, and a host or plan with more configuration access may be the more realistic fix.

Why architecture fixes beat unlimited timeouts

Raising max_execution_time indefinitely often just hides inefficient code instead of fixing it, and it can destabilize a shared server when one script holds a worker open far longer than intended. A better habit is to profile the slow code first, identify the actual bottleneck, and consider a background job system for anything that genuinely takes minutes. The practical order is: measure, optimize, re-architect, and only increase timeouts if real work still demands it.

— Ihor

How we handle PHP configuration when you need server-level access

When the fix genuinely requires server-side changes, having a host that can actually make them matters more than any script edit. Our WordPress-optimized hosting plans include staging environments so you can test timeout and php.ini changes before they touch a live site, and our VPS hosting plans give you direct control over php.ini and PHP-FPM settings when shared hosting limits are the real blocker.

inSave Hosting

Free migration is often offered if moving is the right call, and support teams can help walk through the host-support checklist above directly. Check our shared hosting plans if you're not sure which tier fits, or open a support ticket with the details you've already gathered.

FAQ

What causes the "maximum execution time exceeded" error?

This error means a PHP script ran longer than the max_execution_time value allowed, which defaults to 30 seconds according to the PHP runtime configuration manual. Common causes include slow database queries, large file uploads, or a plugin stuck in a loop.

Does changing wp-config.php always fix WordPress timeouts?

Not always, since a web server timeout set lower than your PHP value will cut the request first regardless of what wp-config.php specifies. Check Apache's Timeout or NGINX's proxy_read_timeout alongside any PHP-side change, as WordPress's own performance documentation recommends aligning both layers.

Is it safe to set max_execution_time to 0?

Setting it to 0 removes the limit entirely, which the set_time_limit manual confirms is technically possible, but it is risky on a shared server since one stalled script can tie up resources other sites need. A bounded value like 300 seconds combined with background processing for longer tasks is generally safer.

Why does my timeout fix work on one script but not another?

Different scripts can be affected by different layers: one may be capped by PHP-FPM's request_terminate_timeout, which the PHP-FPM manual describes as a hard kill independent of max_execution_time, while another hits a web server timeout instead. Testing with ini_get('max_execution_time') and checking server logs for each case usually clarifies which layer is responsible.

When should I contact my hosting provider instead of editing files myself?

Reach out once you've confirmed the active php.ini path, tried a safe wp-config.php or script-level change, and still see the error, since that usually points to a server-level timeout you can't adjust from your account. Shared hosting plans often restrict this access, while managed or VPS hosting typically allows direct configuration changes.

Sources