A maximum execution time error means PHP was still working when the server’s patience ran out. Unlike memory, this almost always points at something genuinely slow rather than something merely large — an external API not responding, an unindexed query, or a batch operation that should have been broken up.
Before you buy, one quick look
Read-only. In wp-admin go to Tools → Site Health → Info → Server and check PHP time limit.
Then note what you were doing when it failed. An import, a backup, and a normal page load are three different problems with the same error message, and knowing which one saves us a step.
Maximum execution time exceeded
Requests run past the server's time limit and get killed mid-execution. We find what is taking so long, fix or optimise it, and adjust the limit where that is genuinely appropriate.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Long pause, then a timeout error | This fix covers it |
| Error names a memory size instead | PHP memory limit exhausted |
| Browser shows 502 or 504 | Gateway timeout diagnosis |
| Only imports and backups fail | This fix covers it |
| Every page is slow but nothing errors | Core Web Vitals remediation |
What you are seeing
- A timeout error after a long pause, rather than an immediate failure
- It may only affect one operation — an import, a backup, a bulk edit
- The admin may hang before failing rather than erroring straight away
- Scheduled tasks may be failing silently at the same time
Common causes
- An external API call with no timeout, waiting on a service that is not answering
- A database query running without an index across a large table
- A bulk operation processing everything in one request instead of batching
- A time limit set very low by the host
- A cron job stacking up because the previous run never finished
What we do
- Take a full backup before touching anything
- Identify the exact operation that is exceeding the limit
- Determine whether the cause is a slow query, a slow external call, or an unbatched job
- Fix the underlying operation where it can be fixed
- Adjust the time limit where the operation is legitimately long-running
- Re-run the failing operation and confirm it completes within limits
What is included
- The failing operation completing reliably
- A note naming what was slow and what was changed
- Scheduled tasks checked, since timeouts often break those too
- The pre-fix backup, kept for 30 days
Not included
- Rewriting a plugin’s architecture so it batches properly — quoted separately
- Fixing an external service that is not responding, which is outside our control
- Full database performance optimisation, which is a separate service
- Malware removal, design changes or content work
Questions about this fix
The error only happens on imports. Is that worth fixing?
Yes, and it is one of the more fixable cases. Imports fail because they try to do everything in a single request. Running them in batches, or raising the limit just for that operation, usually solves it permanently.
Could this be my host being too strict?
Sometimes. Shared hosting often sets a 30-second limit, which is tight for backups and imports. We tell you plainly if the honest answer is that your plan is too small for what you are asking it to do.
Things time out at random, not on any particular page. Why?
That usually points at an external call — a licence check, an analytics ping, a font or script pulled from another server. When that service is slow, every page waiting on it is slow. We find which one and make it non-blocking.
Will this make my site faster generally?
Not necessarily. This fixes operations that exceed a hard limit, which is a different problem from a site that is uniformly slow. If everything is slow, Core Web Vitals remediation is the right service.
Can't I just raise the execution time limit like the memory one?
You can, and it often works for a one-off job like an import — but as a general fix it just makes a slow process take longer instead of failing outright, without addressing why it's slow in the first place.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.