# Stop LiteSpeed cutting off long-running PHP scripts
Source: https://docs.webgee.com/en/hosting/wordpress/execute-php-scripts-with-no-timeout-when-using-litespeed



Some PHP scripts legitimately run for minutes — full-site backups, large
imports, database index rebuilds, WP-Cron jobs. LiteSpeed stops long or silent
requests by default, which can kill them mid-run. Applies to all shared and
reseller hosting, which runs LiteSpeed.

Two separate protections cause this, and they need different fixes. Most
long-running scripts need both.

| Variable        | Stops LiteSpeed from                                    | Needed when                                               |
| --------------- | ------------------------------------------------------- | --------------------------------------------------------- |
| `noabort`       | Killing PHP when the visitor's connection closes        | The script is started and then abandoned, as WP-Cron does |
| `noconntimeout` | Closing a connection that has sent nothing for too long | The script runs a long time before producing output       |

Both are LiteSpeed-specific and must be wrapped in an `IfModule` block so the
rules are ignored on any other web server.

## Set them in .htaccess [#set-them-in-htaccess]

Add this to the `.htaccess` file in your site's document root:

```apache
<IfModule Litespeed>
SetEnvIf Request_URI "(wp-cron|backupbuddy|importbuddy)\.php" noabort noconntimeout
</IfModule>
```

That targets the three scripts most often affected. Replace the names with
whatever your own long-running script is called.

To apply it to every request on the site instead:

```apache
<IfModule Litespeed>
SetEnv noabort 1
SetEnv noconntimeout 1
</IfModule>
```

<Callout type="warn">
  Applying this to every request removes the protection that stops a runaway
  script consuming resources indefinitely. On shared hosting that counts against
  your account's limits. Target the specific scripts that need it.
</Callout>

## Prefer SetEnv over rewrite rules [#prefer-setenv-over-rewrite-rules]

The same result can be achieved with rewrite flags:

```apache
<IfModule Litespeed>
RewriteEngine On
RewriteRule (wp-cron|backupbuddy|importbuddy)\.php - [E=noabort:1,E=noconntimeout:1]
</IfModule>
```

Use `SetEnv` and `SetEnvIf` instead where you can. Rewrite rules are sensitive
to their position relative to other rules — WordPress's own rewrite block in
particular — so a rule placed after the WordPress block may never be reached.
`SetEnv` can go anywhere in the file.

Do not use both approaches for the same script.

## PHP's own limit still applies [#phps-own-limit-still-applies]

These variables control **LiteSpeed**. PHP has a separate limit, and a script
can still be stopped by it:

```ini
max_execution_time = 300
```

Set it in cPanel's **MultiPHP INI Editor**. See
[PHP versions and settings](/en/development).

If a script stops at a consistent time — exactly 30 or exactly 60 seconds —
that is almost always PHP's limit rather than LiteSpeed's.

## Before you reach for this [#before-you-reach-for-this]

A script needing several minutes is often a symptom rather than a requirement.

* **WP-Cron** is better replaced with a real cron job than kept alive. A system
  cron calling WP-CLI is more reliable and does not depend on a visitor
  arriving.
* **Plugin backups** write full copies of the site into your own disk quota, and
  are removed by WebGee's cleanup. Use JetBackup instead — see
  [Files WebGee automatically removes](/en/hosting/understanding-our-internal-auditing-and-cleanup-process).

## Verify [#verify]

Run the script and confirm it completes. If it still stops, check whether it
stops at a fixed time — that points at `max_execution_time`, not LiteSpeed.

## Related [#related]

* [Improve a slow WordPress or WooCommerce dashboard](/en/hosting/wordpress/how-to-improve-a-slow-wordpress-or-woocommerce-dashboard)
* [Files WebGee automatically removes](/en/hosting/understanding-our-internal-auditing-and-cleanup-process)