WordPress Site Down on Shared Hosting: Why CPU Limits Are Throttling Your Site

The slowdown that looks like an outage

You share a link to your latest blog post on social media. Traffic starts flowing. Your website loads fine for the first few hundred visitors. Then it slows down. Pages take 8 seconds to load. Then 12. Then visitors start seeing 503 errors. By the time you check, the traffic spike has passed and your site is loading normally again.

You check your uptime monitor — it shows green. Your hosting dashboard shows no alerts. You might think it was a one-off. It was not. Your hosting provider throttled your CPU because you exceeded the invisible limits of your shared hosting plan.

Shared hosting is the most common type of WordPress hosting. It is affordable, easy to set up, and works well for small sites with predictable traffic. But the moment your traffic grows, or the moment something unexpected happens on the server, the limitations become painfully clear.

The problem is not that shared hosting is bad. The problem is that the failure mode is invisible. Your site does not crash — it degrades. And unless you are monitoring response times, you have no idea it is happening.

How shared hosting actually works

A shared hosting server is a single physical machine running hundreds of websites. Every account on that server shares the same CPU, RAM, disk space, and network bandwidth. Your hosting provider uses software — typically CloudLinux with LVE containers — to enforce resource limits on each account.

Your "unlimited" hosting plan is not actually unlimited. The terms of service — which almost nobody reads — specify CPU seconds per hour, concurrent PHP processes, and memory limits. When your site exceeds any of these limits, the hosting provider throttles your account.

Throttling means your PHP processes are slowed down or queued. Instead of executing immediately, your page requests wait in line. The server is not down — it is artificially slowing your site to protect the other accounts on the same machine.

From your visitor's perspective, the site loads in 15 seconds instead of 2. Or it shows a 503 Service Unavailable error. Or it shows a partial page with missing images and broken CSS. The experience is terrible, but your hosting dashboard shows no problem.

The four ways shared hosting kills your site

1. CPU throttling during traffic spikes

Every page load on a WordPress site requires PHP to execute. PHP queries the database, processes template files, runs plugin hooks, and generates the HTML that gets sent to the browser. Each page load consumes CPU time.

On shared hosting, you are allocated a certain number of CPU seconds per hour. Under normal traffic, you stay well below this limit. But when traffic spikes — a social media post goes viral, you send an email campaign, or a search engine starts indexing your site aggressively — you blow through your CPU allocation.

The hosting provider does not send you a warning. They do not email you saying "you are approaching your CPU limit." They throttle your account silently. Your site slows to a crawl. When the traffic subsides, the throttling lifts and your site returns to normal speed. You might never know it happened unless a visitor complains.

For WooCommerce sites, this is especially dangerous during sales events. The exact moment you are driving the most traffic — when you have the highest chance of converting visitors into customers — is the moment your hosting throttles your site into unusability.

2. The noisy neighbour effect

Your website is not the only one on that server. There might be 200 other sites sharing the same machine. If one of those sites gets a bot attack, runs a broken cron job that loops infinitely, or has a plugin that consumes excessive memory, it affects every other site on the server.

The hosting provider's resource isolation is supposed to prevent this. In practice, it is imperfect. Disk I/O is the hardest resource to isolate — when one account hammers the disk with large database queries, every other account on the same physical disk feels the slowdown.

You have no visibility into this. You cannot see who the noisy neighbour is. You cannot see what they are doing. All you know is that your site is slow and nothing you do on your end fixes it.

3. Resource limit suspension

Throttling is the first response. If your site continues to consume excessive resources despite throttling — or if the resource usage spikes too high too fast — many hosting providers escalate to account suspension.

Account suspension means your entire site goes offline. Visitors see a generic "Account suspended" page or a blank page. Your files, database, and emails are all inaccessible. The hosting provider sends you an email explaining that you violated their resource usage policy and need to "optimise your site" before they will reinstate it.

The suspension email might arrive in minutes. It might arrive in hours. It might go to spam. Meanwhile, your site is completely down and you have no way to fix it until the hosting provider responds to your support ticket.

According to the WordPress documentation, WordPress itself recommends at minimum PHP 7.4, MySQL 5.7 or MariaDB 10.4, and HTTPS support. But the documentation does not address the CPU and memory limits that shared hosting providers impose — limits that determine whether your site actually performs under real-world conditions.

4. Silent throttling during off-peak maintenance

Hosting providers run maintenance tasks on their servers — backups, security scans, software updates, disk defragmentation. These tasks consume server resources. When maintenance runs during business hours, every site on the server experiences a performance dip.

Most hosts schedule maintenance for off-peak hours. But "off-peak" depends on where the server is located, not where your customers are. If your server is in the US and your customers are in Europe, "off-peak" maintenance at 3am US time might be 9am in London — right when your European visitors are arriving.

The maintenance is invisible to you. The performance dip looks like your site is just having a slow day. Without response time monitoring, you never connect the dots.

Why standard uptime monitoring misses throttling

A standard uptime monitor sends an HTTP request and checks if the server responds with a 200 status code. If it does, the site is "up." If it does not, the site is "down."

When your shared hosting provider throttles your CPU, the server still responds. It just takes 10 seconds instead of 1 second. Most uptime monitors have a generous timeout — 30 seconds or more — so the request eventually succeeds and reports your site as "up."

But a site that takes 10 seconds to load is not "up" in any meaningful sense. Visitors leave after 3 seconds. Google penalises slow sites in search rankings. Conversion rates drop by 7% for every additional second of load time. Your uptime monitor says 100% uptime while your site is effectively unusable.

This is why response time monitoring is essential. It does not just check whether the server responded — it checks how fast it responded.

How to detect hosting throttling with Uptrue

Uptrue's HTTP monitoring records the response time on every check. When your hosting provider throttles your site, the response time spikes — and Uptrue alerts you immediately.

Step 1: Set up an HTTP monitor with response time alerting

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor from your dashboard
3. Select HTTP/HTTPS as the monitor type
4. Enter your homepage URL
5. Set expected status to 200
6. Set the check interval to 1 minute
7. Set a response time threshold — alert if response time exceeds 3 seconds
8. Configure alerts — Slack, email, or Microsoft Teams

Now, every time your site takes longer than 3 seconds to respond, you get an alert. This catches throttling, noisy neighbour slowdowns, database performance issues, and any other cause of degraded performance — not just complete outages.

Step 2: Monitor multiple pages for partial throttling

Throttling does not always affect every page equally. Your homepage might be cached and load quickly while your WooCommerce shop page, which runs heavy database queries, gets throttled into unusability. Set up monitors for:

• Homepage
• Shop or product category page (if WooCommerce)
• Contact page
• Any page running resource-heavy plugins
• Your most popular blog post

Step 3: Track response time trends over time

Uptrue records the response time of every check. Over days and weeks, you build a clear picture of your site's performance. You can see:

• Whether response times are gradually increasing — a sign you are outgrowing your hosting plan
• Specific times of day when throttling occurs — which often correlates with server maintenance or peak usage periods
• Sudden spikes that correspond to traffic events or plugin activity
• Whether a hosting provider change actually improved performance

Step 4: Set up a keyword monitor as a backup

1. Click Add Monitor
2. Select Keyword as the monitor type
3. Enter your homepage URL
4. Set the keyword to your site title or a phrase that always appears on your homepage
5. Set the check type to "Page must contain"
6. Set the interval to 1 minute

If throttling escalates to a full suspension and your host replaces your site with a "suspended" page, the keyword monitor catches it. Your expected content is gone, replaced by the suspension notice.

Step 5: Configure alerts that reach you during business hours

Throttling is a performance problem, not necessarily an emergency. Configure your alerts appropriately:

• Slack — response time threshold alerts go to a performance channel for visibility
• Email — summary alerts for response time trends
• Webhook — pipe response time data into your own analytics or dashboards
• Microsoft Teams — for teams using the Microsoft ecosystem

What to do when you confirm throttling

Once you have the data showing that your hosting is throttling your site, you have three options.

Optimise your site to stay within limits

Install a caching plugin to reduce PHP execution. Optimise your database. Remove plugins you are not actively using. Lazy-load images. Move static assets to a CDN. These changes reduce the CPU and memory your site consumes per page load, keeping you within your hosting limits for longer.

Upgrade your hosting plan

Most shared hosting providers offer tiered plans with different resource limits. Upgrading gives you more CPU seconds, more PHP workers, and more memory. This buys time but does not solve the fundamental problem — you are still on shared infrastructure with noisy neighbours and invisible limits.

Move to managed WordPress hosting or a VPS

If your site is generating revenue, the cost of better hosting is trivial compared to the revenue lost during throttling episodes. Managed WordPress hosts provide dedicated resources, server-level caching, and proactive performance optimisation. A VPS gives you guaranteed CPU and RAM that no other site can consume. Either option eliminates the noisy neighbour problem entirely.

Stop guessing why your site is slow

Shared hosting throttling is invisible by design. Your hosting provider does not alert you when they throttle your CPU. Your uptime monitor says the site is up. Your hosting dashboard shows no warnings. Meanwhile, your visitors wait 15 seconds for a page to load and leave.

Uptrue checks your site every 60 seconds and tracks the response time on every check. When your hosting provider throttles your site, you see it in the data. When response times exceed your threshold, you get an alert. You stop guessing and start knowing.

Frequently asked questions