# Resolving Magento 500 admin errors and timeouts

> Learn why Magento 2 throws 500 errors or times out during admin operations, and how to fix the most common causes on Kualo hosting.

Source: https://www.kualo.com/knowledgebase/magento-troubleshooting/magento-2-500-errors-and-timeouts-when-saving-products-or-processing-in-the-admin
Updated: 2026-06-11

---

Saving a complex product, processing a refund, or running a bulk admin action in Magento 2 puts far more load on the server than a normal page view.

That extra load can push the operation into a 500 error, a timeout, or a silent failure before it completes. This article walks you through identifying which of the four common causes you are dealing with - a PHP limit, concurrent process exhaustion, a Cloudflare timeout, or a search service problem - and applying the right fix for each.

## Check the logs before you change anything

The fastest way to narrow down the cause is to read Magento's own log files in your store's `var/log/` directory. The two files to check first are `var/log/exception.log` for application errors and `var/log/system.log` for general warnings.

For a detailed guide on finding and reading these files, see [Debugging Magento 2 errors: log locations and how to read them](/knowledgebase/magento-troubleshooting/debugging-magento-2-errors-log-locations-and-how-to-read-them).

Here is what each common culprit looks like:

- **PHP timeout or memory exhaustion** - a message such as `PHP Fatal error: Maximum execution time of X seconds exceeded` or `PHP Fatal error: Allowed memory size of X bytes exhausted`.
- **Concurrent process exhaustion** - intermittent 503 "Resource Limit Is Reached" errors in the browser, often with nothing in Magento's logs because the request was refused before PHP started.
- **Cloudflare proxy timeout** - the browser shows a Cloudflare error 524 page, but the server logs show no error, because Cloudflare gave up waiting while the server was still working.
- **OpenSearch or Elasticsearch exception** - a message referencing `OpenSearch`, `Elasticsearch\Common\Exceptions`, `No alive nodes`, or a connection refused error pointing to a host and port.

Identify which pattern matches your situation, then jump to the matching section below.

## Fix PHP time and memory limits

If your logs show a PHP timeout or memory exhaustion error, raise the relevant PHP limit for your account.

On Kualo hosting, PHP limits are managed through the **CloudLinux PHP Selector**, which you access in cPanel as **Select PHP Version**. This is the correct and only reliable way to change PHP settings on our platform.

The two settings most relevant to admin timeouts are:

- `max_execution_time` - the maximum number of seconds a PHP script may run. For Magento admin operations, `300` (five minutes) is a reasonable starting point; large bulk operations may need `600`.
- `memory_limit` - the maximum memory a single PHP process can use. Magento needs `756M` for admin work, and this suits most stores as the everyday value.

### Size memory_limit against your account, not just Magento

`memory_limit` is a ceiling per process, and PHP runs many processes at once: every visitor request, every admin user, cron jobs, and any API integrations each get their own. Your hosting account also has a total memory allowance shared between all of them - you can see it in cPanel under **Resource Usage**.

That means the right global value is the lowest one your store actually needs day to day, not the highest one that makes a particular operation succeed. Most requests use a fraction of the ceiling, but heavy operations genuinely reach it, and a global limit of `1024M` or more on an account with a few gigabytes of memory means a handful of simultaneous heavy requests can consume your entire allowance - causing the very faults and errors you are trying to fix.

For the occasional operation that needs more - a big import, a full reindex, an upgrade - do not raise the global value. Run the task over SSH with a one-off limit instead:

```bash
php -d memory_limit=2G bin/magento indexer:reindex
```

This gives that single command the headroom it needs without changing the ceiling for every web request on your site.

To change the global values:

1. Log in to cPanel and open **Select PHP Version**.
2. Click the **Options** tab.
3. Find `max_execution_time` and `memory_limit` in the list, enter your new values, and save.
4. Retry the operation in the Magento admin.

For a full walkthrough, see [How to manage the PHP version in cPanel using the Select PHP Version tool](/knowledgebase/cpanel-php/how-to-manage-the-php-version-in-cpanel-using-the-select-php-version-tool). If your store genuinely needs high limits across the board, or raising them causes memory faults in Resource Usage, contact our support team - that is usually a sign the account needs more memory rather than a bigger ceiling.

## Fix concurrent process exhaustion (508 errors)

Your hosting account has a limit on how many PHP processes can run at the same time. The Magento admin is unusually good at hitting it: the dashboard and grids poll via ajax, bulk operations hold a process open for minutes, and any connected integrations (feeds, ERPs, marketplaces) make API calls of their own. When everything coincides, new requests are refused with a 508 "Resource Limit Is Reached" error until a process slot frees up.

The giveaways are that the errors are intermittent, they get worse during bulk operations or busy trading periods, and Magento's own logs show nothing for the failed requests.

You can see whether you are hitting the limit in cPanel under **Resource Usage** - look for entry process (EP) faults. See [Understanding Resource Usage in cPanel](/knowledgebase/cpanel-account/understanding-resource-usage-in-cpanel) for how to read the graphs.

To reduce the pressure:

- Run heavy operations over SSH instead of the browser (see the next section) - a CLI process does not count against the web process limit in the same way, and it frees the admin for normal use.
- Schedule imports, feed generation and API-heavy integrations for quiet periods rather than alongside admin work.
- If you are regularly hitting the limit during normal trading, your store has outgrown its current allowance - contact our support team and we can review your resource limits or recommend a more suitable plan.

## Run bulk operations via CLI or cron instead

The most reliable way to avoid PHP timeouts, process exhaustion and Cloudflare timeouts all at once is to avoid triggering heavy operations through the browser entirely.

Magento 2 exposes most bulk and maintenance tasks as CLI commands. Running them over SSH bypasses the web server timeout, the proxy in front of your site, and the browser session. For example, to reindex everything:

```bash
php bin/magento indexer:reindex
```

Run commands from your Magento root directory. See [Essential Magento 2 commands to run over SSH](/knowledgebase/magento-getting-started/essential-magento-2-commands-to-run-over-ssh) for a reference list, and if you are not yet set up for SSH access, see [Using SSH on Kualo hosting: a getting-started guide](/knowledgebase/dev-cli/using-ssh-on-kualo-hosting-a-getting-started-guide).

For tasks Magento queues automatically, make sure your Magento cron job is configured correctly so the queue is processed in the background without a browser request keeping a connection open.

## Fix Cloudflare proxy timeouts (error 524)

If the browser shows a Cloudflare error 524 page but your server logs show no error, Cloudflare's proxy cut the connection before your server finished.

Cloudflare waits a fixed time - around 100 seconds on Free, Pro and Business plans - for the origin server to respond to a proxied request. A Magento admin operation that takes longer than that will return a 524 to the browser even though the server is often still working, and may even complete successfully behind the scenes. This timeout is set at Cloudflare's end; it is not something we can change for you, and raising `max_execution_time` does not affect it.

Your options:

- **Use CLI or cron instead** - as above, running the operation over SSH bypasses Cloudflare entirely and is the right long-term approach for anything that regularly takes more than a minute.
- **Temporarily grey-cloud the domain** - in your Cloudflare DNS settings, switch the relevant record from proxied (orange cloud) to DNS-only (grey cloud) while you run the long operation, then switch it back. Allow a few minutes for the change to take effect.

For general guidance on using Cloudflare with your account, see [How to set up Cloudflare with your Kualo hosting account](/knowledgebase/domains-dns-ns/how-to-set-up-cloudflare-with-your-kualo-hosting-account).

## Fix search service exceptions (OpenSearch or Elasticsearch)

If `exception.log` shows an OpenSearch or Elasticsearch error, the problem is the search service rather than a PHP limit. Magento uses the search service heavily during product saves and admin grid operations, so a broken connection causes failures that look like generic 500 errors.

On our hosting, the search service runs as a dedicated instance on your account, managed through the **ElasticSearch** plugin in cPanel, where you can check its status, restart it, and view the connection details (host `127.0.0.1` and a port unique to your account) that your Magento configuration must match. Verify those against **Stores > Configuration > Catalog > Catalog Search** and use the **Test Connection** button.

For the full diagnostic walkthrough, including restarting the service, reindexing, and fixing mapping mismatches after upgrades, see [Resolving Magento 2 OpenSearch/Elasticsearch errors causing broken search and category pages](/knowledgebase/magento-troubleshooting/resolving-magento-2-opensearch-elasticsearch-errors-causing-broken-search-and-category-pages).

## A note on admin session timeouts

A blank page or an unexpected redirect to the Magento login screen is not always a 500 error. Magento has its own admin session timeout, separate from the PHP execution timeout, and a session expiring mid-operation can produce a blank page or a silent redirect rather than a clear error.

If you are being logged out before long operations complete, extend the session under **Stores > Configuration > Advanced > Admin > Security > Admin Session Lifetime**. The default is 900 seconds (15 minutes); 3600 gives you an hour of working time.

## When to contact our support team

Some causes are on our side to resolve. Contact our support team if:

- You have raised PHP limits to reasonable values but operations are still being terminated, which may indicate resource throttling at the account level.
- Resource Usage shows persistent entry process or memory faults during normal trading.
- The search service will not return to Active in the cPanel plugin, or the connection test fails with settings that match the plugin's details.
- Your logs show a 500 with no corresponding entry in `var/log/exception.log` or `var/log/system.log` and no Cloudflare involvement.

When you contact us, include the relevant log entries, the PHP limit values you have set, and a description of the exact operation that triggers the error - this lets us diagnose the problem without going back and forth for basics.

You can raise a ticket from the [Kualo Client Area](https://my.kualo.com). See [How to Create a Support Ticket in MyKualo](/knowledgebase/getting-started/how-to-create-a-support-ticket-in-mykualo) if you need help doing that.

---

_Source: Kualo Knowledgebase — https://www.kualo.com/knowledgebase/magento-troubleshooting/magento-2-500-errors-and-timeouts-when-saving-products-or-processing-in-the-admin · © Kualo Ltd._