Maximum execution time exceeded in WordPress – causes and solutions

You’re working in WordPress and suddenly see “Fatal error: Maximum execution time of 30 seconds exceeded.” Don’t panic — this error is common and usually fixable. In this knowledge base article I explain clearly what this error means, why it happens, and how to fix it step by step. It’s aimed at small businesses and freelancers with WordPress sites. No heavy technical jargon, just practical solutions to regain control of your site.

What does “Max execution time exceeded” mean?

The message “Maximum execution time of X seconds exceeded” means a PHP script in WordPress ran too long and was terminated by the server. In other words, a process took longer than the limit (usually 30 seconds, sometimes 60). To prevent one script from overloading the server, PHP stops execution once the time limit is reached. WordPress then shows a fatal error. You’ll often see this while installing or updating plugins, themes, or WordPress core. The number in the message (e.g., 30) is the limit set by your host. It exists to prevent abuse — so scripts can’t run forever.

Although “Fatal error” sounds serious, it doesn’t mean your site is permanently broken. It’s a common WordPress issue. You’ll usually notice it when a dashboard action fails with that message. Sometimes the front‑end shows “There has been a critical error on this website” if an important process breaks halfway. The good news: you can often fix this by increasing the maximum execution time.

Why does this error happen? (Causes)

Why would a script run longer than 30 seconds? Common reasons include:

• Heavy plugins or themes: a plugin or theme runs a big task and isn’t optimized, using lots of time/resources. Examples: a backup plugin creating a full backup, a page builder updating thousands of elements, or an import tool processing a large dataset. These can exceed 30 seconds.
• Large uploads/imports: uploading a huge file (e.g., high‑res video or large XML import) can take longer than the limit, causing a timeout.
• Slow server or shared hosting: on shared hosting, limits are often low (30s or less). If the server is slow or busy, even a moderate task can exceed the limit.
• Stuck processes: a script can hang due to a bug or waiting for a slow external service. Time keeps ticking until the limit is hit.
• Security limit: the limit exists to stop abuse. In rare cases malicious scripts would run forever; the time limit kills them. But it can also affect legitimate tasks.

Bottom line: the error appears when a task takes too long — often due to a plugin, theme, or heavy process. Usually you can solve it by raising the limit or optimizing the task.

Step‑by‑step fixes (shared hosting)

On shared hosting you often have limited access, but there are a few ways to increase max execution time. Try these methods in order. Tip: always make a backup before changing system files.

Method 1: Increase max execution time via cPanel (php.ini or MultiPHP INI Editor)

The most direct way is to change the PHP setting in your hosting panel. In cPanel, use MultiPHP INI Editor (sometimes called Select PHP Version or PHP Options). Steps:

1. Log in to cPanel and go to Software (or Advanced). Click MultiPHP INI Editor.
2. Select your domain or PHP version. You’ll see a list of PHP settings.
3. Find max_execution_time (often 30 or 60).
4. Increase it — for example to 60 seconds. For heavier tasks you can try 90 or 120. (Don’t set extreme values like 300+ unless truly needed.)
5. Save the change.

Go back to WordPress and retry the action. If the error persists, increase the value further (e.g., 90 or 120). If it still fails, the problem may be elsewhere (e.g., a bad plugin).

Note: some hosts don’t allow direct PHP settings. If you don’t see the INI editor, try method 2 or 3, or contact your host (method 4).

Method 2: Increase the limit via wp-config.php

If cPanel isn’t available, you can ask WordPress to allow more execution time. Add a line to wp-config.php:

1. Open wp-config.php via FTP or File Manager (usually in public_html). Make a backup and edit the file.
2. Add this line just above “That’s all, stop editing! Happy publishing.”:

set_time_limit(60);

This allows scripts to run for 60 seconds instead of 30. You can set 120 for 2 minutes if needed.

3. Save the file and upload it back if needed.
4. Retry the action that caused the error.

If nothing changes, your host may ignore set_time_limit for security reasons. Move to method 3.

Method 3: Increase max execution time via .htaccess

You can also increase the limit using .htaccess (only if your host supports PHP overrides in .htaccess, typically Apache). Don’t use this together with method 2.

Steps:

1. Open .htaccess in the WordPress root (same place as wp-config.php). It’s hidden — enable hidden files. Back it up first.
2. Add this line at the bottom:

php_value max_execution_time 60

3. Save and retry your action.

If you see a 500 Internal Server Error after this, your host doesn’t allow this setting. Remove the line and restore .htaccess.

Method 4: If nothing works, contact your host

If you tried everything and the error persists, contact your hosting provider. Some hosts enforce hard limits you can’t change. Ask them to raise max_execution_time for your account (e.g., to 60 or 120 seconds).

Good hosts can also help identify why your site hits the limit. Sometimes they’ll reveal a misbehaving plugin or suggest a stronger hosting plan if your site often runs long tasks. Don’t hesitate to ask — that’s what support is for.

Proactive prevention

Ideally you prevent these errors. Here are practical, host-agnostic tips:

• Script monitoring: track how long processes run via logs or APM tools. If a cron job or plugin keeps hitting the limit, intervene early — run it off‑peak or reduce its frequency.
• Code/plugin optimization: optimize queries, disable unnecessary features, or split heavy tasks into smaller batches (so each run stays under the limit). For example, an import script can run 100 records at a time instead of everything at once.
• Server tuning: ask your host to raise limits for background jobs when needed, and run heavy tasks via WP‑CLI or queues instead of web requests so visitors aren’t affected.
• Regular maintenance: keeping WordPress and plugins up to date reduces inefficiencies. Older versions often contain bugs that slow tasks down. Test updates before rollout to avoid surprises.

With proactive care, most “max execution time” problems never happen. And if something does hang, you can fix it before it becomes a user‑visible error.

Closing thought