Guide PHP & Development

How to increase PHP max execution time

Where max_execution_time lives, how to raise it without root access, and the point at which a longer limit stops being the right answer.

iFastHosting Support Team Updated 26 August 2026 5 min read Beginner

max_execution_time is the number of seconds PHP allows a single script to run before it stops it. Run past it and PHP produces an unambiguous error:

Fatal error: Maximum execution time of 30 seconds exceeded

The default on most hosting is 30 seconds, which is plenty for an ordinary page request and nowhere near enough for a large import, a report that scans thousands of rows, or a bulk operation triggered from an admin screen. Raising the limit is the right move for jobs like that — the trick is raising it in the right place, and knowing when a longer script is not actually the better answer.

Where to change it

On shared hosting, without needing root access, you have three options depending on how targeted you want the change to be:

The PHP settings area of your control panel. Changes the default for the whole site or account. Use this when several scripts across the site legitimately need more time.
A user-level php.ini or .user.ini file in the site's directory:

max_execution_time = 120

Inside the script itself, for a one-off job that needs more time than everything else on the site:

<?php
set_time_limit(120);
// long-running work here

set_time_limit() only counts CPU time PHP is actively running

Time spent waiting on a database query or an external API response is not always counted against this limit the same way as pure PHP execution, and behaviour here varies by SAPI. A script that appears to hang far longer than its configured limit before finally erroring is usually waiting on something external, not violating the setting — see calling an external API from PHP if that something is a remote request.

Value guide

Job	Reasonable value
Normal page load	30 (the default is usually fine)
Admin-triggered export or report	120–300
Large one-off data migration	Run it as a scheduled script over cron instead of a browser request — see below

When a longer limit is the wrong fix

A script that needs several minutes to finish is often better run as a scheduled task than as something a browser sits and waits for. Browsers, proxies and some hosting layers impose their own timeouts well under a generous PHP setting, so a script can still be cut off even after you have raised max_execution_time — the request simply never gets the chance to finish waiting on the client end. Moving long jobs to a scheduled PHP script run over cron avoids that ceiling entirely, because nothing is waiting on a browser connection.

CLI scripts are not bound by this the same way

PHP run from the command line, including cron jobs, defaults to max_execution_time = 0 — unlimited — on most configurations, independent of whatever the web-facing value is set to. If a script times out through a browser but runs to completion fine over SSH or cron, that difference in default is very likely why, not evidence that the code itself is broken.

What usually needs a longer limit

A handful of jobs account for most requests to raise this setting, and it is worth recognising which one you actually have:

Bulk imports and exports — a spreadsheet of products, a mailing list, a full database dump processed row by row through PHP rather than at the database level.
Third-party API calls made in a loop — fetching or pushing one record at a time to an external service instead of using its batch endpoint, where one available.
Image or media processing — resizing, converting or watermarking a large batch of files in a single request.
Search indexing or cache warming — an operation that touches every page or product on a large site at once.

All four are better handled as scheduled or queued jobs than as a single browser request stretched to its limit, precisely because they tend to grow — a script that comfortably finishes today at 5,000 rows will not comfortably finish next year at 50,000, and a hard-coded execution time ceiling is not a plan for that growth the way a scheduled job that simply runs a bit longer is.

Confirming the change worked

<?php echo ini_get('max_execution_time');

If the value has not changed after editing the setting, check that you edited the PHP version actually serving the site — see checking your PHP version — and that nothing later in the script calls set_time_limit() with a smaller number, which overrides whatever the server-level setting allowed.

If it still fails after raising the limit

A script that still exceeds a generous limit is usually doing more work per item than it needs to — an unindexed database query, an API call repeated inside a loop instead of batched, or an operation that scales badly as the data grows. Read the error log for the exact line the timeout hit, and look there first before raising the number again.