Resolving Script Execution Timeouts in Shared Hosting Environments

A script timeout happens when a PHP page runs longer than something in the chain is willing to wait. On shared hosting that is common with imports, exports, reports and calls to slow outside services. This guide explains which limit you are hitting on Domain India hosting, why raising max_execution_time often changes nothing, and how to restructure long work so it finishes.

1. Which limit are you hitting?

A web request passes through several layers, and each has its own clock. The error you see tells you which one ran out.

The measured values on our shared servers (24 September 2026):

• cPanel: nginx sits in front of Apache and waits about 90 seconds for a reply. The default PHP max_execution_time is 120 seconds, so on a web request the 90-second nginx limit is the one you hit first.
• DirectAdmin: there is no nginx layer. The default PHP max_execution_time in the server's PHP builds is 30 seconds.
• Command-line PHP (cron jobs) has no execution time limit by default, but your plan's CPU and memory limits still apply.

2. Why raising max_execution_time rarely fixes it

On cPanel, a request that runs longer than about 90 seconds gets a 504 from nginx even if PHP would keep going. Raising max_execution_time to 300 changes nothing for the visitor, and the nginx timeout is server-wide, so it can't be changed for one account.

On DirectAdmin, raising the PHP limit may let a slow request finish, but it only hides the problem: a request that takes minutes also holds one of your account's PHP process slots the whole time. A few of those at once and visitors start getting 508 errors. See understanding hosting resource limits.

If you still need to change PHP settings for other reasons, cPanel's MultiPHP INI Editor is covered in how to edit php.ini in cPanel. Don't put php_value lines in .htaccess: PHP does not run as an Apache module on our servers, and those lines cause a 500 error.

3. Find the slow part

Measure before you change anything. Add timing to the script and write it to a log file outside your web folder:

<?php
$start = microtime(true);
error_log('job started', 3, __DIR__ . '/../logs/job.log');

$t = microtime(true);
$result = $db->query($sql);
error_log(sprintf("query took %.2fs\n", microtime(true) - $t), 3, __DIR__ . '/../logs/job.log');

error_log(sprintf("total %.2fs\n", microtime(true) - $start), 3, __DIR__ . '/../logs/job.log');

Then read the error log for the time of the failure; see reviewing error logs in cPanel and DirectAdmin. The usual culprits are one slow query, one slow outside API call, or a loop over far more rows than you expected.

4. Make each request shorter

A batch loop that resumes where it stopped looks like this:

<?php
// process up to 200 pending rows per run, then stop
$rows = $db->query("SELECT id, email FROM jobs WHERE status = 'pending' ORDER BY id LIMIT 200");
foreach ($rows as $row) {
    process($row);
    $db->prepare("UPDATE jobs SET status = 'done' WHERE id = ?")->execute([$row['id']]);
}

For outside calls with PHP's HTTP stream functions, set the timeout explicitly:

<?php
$ctx = stream_context_create(['http' => ['timeout' => 5]]);
$response = @file_get_contents('https://api.example.com/rates', false, $ctx);
if ($response === false) {
    error_log('rates API did not answer in 5s');
}

Several PHP functions are disabled on our shared servers, including exec, proc_open and, on most DirectAdmin sites, curl_exec. Check PHP disabled functions on shared hosting before you rely on one.

5. Move long work out of the browser

Some jobs are long by nature: a large import, a newsletter batch, a nightly report. Don't run them from a web page at all.

There is no Redis or other queue service on shared hosting, so a database table is the simplest queue. If the work must run continuously, needs a worker that stays running, or needs its own timeouts, it belongs on a VPS.

6. When a VPS is the right answer

On a VPS you control every layer, so you can set nginx's proxy_read_timeout, Apache's Timeout, PHP-FPM's request_terminate_timeout and PHP's max_execution_time to suit your application, and run queue workers under a process manager. Keep the front layer's timeout slightly longer than the one behind it, so errors come from PHP with a clear message rather than a bare 504.

A Domain India VPS is self-managed: you get full root access and look after the operating system, security and software yourself. Try the steps above first; most timeout problems are fixed by shorter requests, not bigger servers.

7. Where Domain India fits

For PHP sites that do their heavy work in batches and cron jobs, shared hosting is enough. For long-running workers and custom timeouts, choose a VPS.

Cards show Domain India list prices on 19 September 2026, excluding 18% GST. For WordPress-specific errors, see resolving common gateway errors in WordPress.

Ready to fix it? Time the slow part, split the work into batches, and move long jobs to a cron job. If your application needs its own timeouts or workers, compare VPS plans, or open a support ticket with the page, the error and the time it happened.