When to Switch Web Hosting: 8 Warning Signs and How to Measure Them
When should you switch web hosting providers?
You should switch web hosting when your site shows measurable, repeating problems with downtime, speed, resource limits, outdated software, support, security, backups or pricing, and your provider still cannot fix them after a support ticket or a plan upgrade. In short, logs should drive the decision, not frustration.
In this guide we walk through eight warning signs one by one. For each sign we explain what you will notice, how to measure it and when it deserves real attention. We also give you a simple decision tree for the classic question: upgrade or move? We keep the migration steps short, because we already have a separate checklist for that.
One honest note first. Talha Aslan and team is a digital marketing and web team, not a hosting company. So we do not praise or criticize any specific provider here. Instead, we base the technical points on official documentation and cite the source for every number.
Why is it risky to decide without measuring first?
A decision without data often aims at the wrong target. For example, if your site feels slow, it is tempting to blame the host. However, the real cause might be a heavy plugin, oversized images or a disabled cache. If you move, the same site brings the same problem to the new server, and you lose both time and money.
That is why we suggest setting up four simple records before you decide:
- Uptime monitoring: an external service that checks your site every minute or every few minutes.
- Speed tests: Lighthouse, PageSpeed Insights or a command line TTFB check, run on the same page at different times of day.
- Resource usage graphs: the CPU, memory, entry process and disk I/O charts in your control panel.
- Support response log: when each ticket opened, when the first reply arrived and when the issue was closed.
Two to four weeks of records usually give you a clear picture. Then you can say "time to first byte is consistently high in the evening" instead of "it feels slow." Moreover, that evidence makes your conversation with the provider much more productive.
Sign 1: Does your site go down often, with poor uptime?
The first sign is the most obvious one: your site sometimes does not load. Visitors see a blank page, a timeout or a 5xx error. A short outage can happen with any provider. Still, if it repeats several times a week, you are looking at a pattern.
Measure uptime with your own monitoring, not only with the provider's status page. For a quick spot check, our is it down checker helps. For continuous records, however, you need an external monitoring service.
Example calculation: a 30 day month has 43,200 minutes. An uptime of 99.9 percent allows roughly 43 minutes of downtime per month. At 99 percent, that number rises to about 432 minutes, which is more than 7 hours. So convert the percentage in your contract into minutes before you judge it.
Also look at when outages happen. If they always fall into a night maintenance window, that is one thing. If they repeat during busy daytime hours, they point to capacity or infrastructure problems instead. Note whether the provider announced the maintenance in advance, too.
Downtime affects search as well. Google Search Central explains in its official documentation on HTTP errors that 5xx and 429 responses make Google's crawlers slow down temporarily, and that URLs which persistently return a server error eventually drop from the index. To understand one common error, read our 503 Service Unavailable guide.
Sign 2: Is your site slow, with a consistently high TTFB?
The second sign is slowness. That said, not every slow page is the host's fault. The best way to isolate the server side is TTFB, or time to first byte. web.dev defines it as the time between the start of navigation and the moment the first byte of the response arrives.
According to web.dev's TTFB guide, most sites should aim for 0.8 seconds or less, while values above 1.8 seconds count as poor. TTFB includes redirect time, DNS lookup, connection and TLS negotiation, and the time the server needs to start answering.
For a rough check from the command line, you can use this:
curl -o /dev/null -s -w "dns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nfirst byte: %{time_starttransfer}\n" https://example.com/Repeat the test at different times of day on a page that bypasses the cache. If DNS and connect times look normal but the first byte arrives late, the problem most likely sits on the server or in the application. Next, follow the diagnostic order in our article on server side causes of a slow website. To rule out front end issues, a Lighthouse performance test is also useful.
Sign 3: Do you keep hitting resource limit errors?
On shared hosting, every account has limits for CPU, memory, concurrent processes and disk reads and writes. These limits are normal and fair, because you share the server with other accounts. The problem starts when you hit them all the time.
Typical symptoms look like this:
- A "resource limit reached" style message after a campaign or a newsletter send.
- A slow admin area and timeouts when you save content.
- Cron jobs that stop halfway.
- Usage graphs in your panel that regularly touch the ceiling.
To measure this, open the resource usage screen in your control panel. Note which resource hits the limit and at what time. For instance, if CPU fills up every night at the same hour, a backup or a cron job may be the culprit. In that case, you do not need a new host; moving the job to a quieter hour or splitting it up is enough.
On the other hand, if you hit the limits during normal traffic, your site has outgrown the plan. At that point the first question is not "should I move?" but "should I upgrade?" If you want to understand how account isolation works on shared servers, our CageFS article explains it.
Sign 4: Does your host support current PHP and software versions?
The fourth sign is quiet but dangerous. If your provider is stuck on old PHP, database or web server versions, your site slowly collects security gaps. In addition, new plugin and theme releases may refuse to run on an old stack.
The official PHP supported versions page describes the lifecycle clearly. Each release branch receives two years of full support from its first stable release, then two more years of critical security fixes only. After those four years, the branch reaches end of life and no longer receives patches.
How do you check it? Open the PHP version selector in your panel and compare the available versions with the official support table. If even the newest option on offer is a branch without security support, treat that as a clear warning. If you use cPanel, our guide on changing the PHP version in cPanel shows the steps.
Still, test your site on a current version in a staging copy first. Sometimes the host offers the new version, yet the site's old code cannot handle it. In that case, the fix is updating the code, not moving to another host.
Sign 5: Is the support team slow or unhelpful?
Hosting is not only a server. It is also the team you contact when something breaks. If you wait hours for a reply during an outage, or every ticket comes back with a canned answer, even great hardware will not protect you.
Measure this too. In a simple sheet, track the topic of each ticket, the time you opened it, the time of the first reply, the time it was resolved and whether the fix lasted. After a few weeks, you will see your average first response time and how often the same issue returns.
You can recognize good support by these signs:
- The first reply arrives within the time the provider promises.
- The reply explains the cause instead of just saying "fixed."
- Technical questions get technical answers, not a push to upgrade.
- When an issue repeats, the team looks for the root cause.
Check the support channels as well. Do they answer only by email, or is there phone or live chat for emergencies? Do their working hours overlap with yours? For online stores in particular, the answers to these questions turn directly into lost or saved revenue.
Sign 6: What do security incidents and unpatched servers tell you?
If your site has been infected with malware more than once, if your email keeps landing on blocklists, or if the provider delays security updates for months, that is a serious sign. However, you need to split responsibility correctly here.
On shared hosting, the operating system, the web server and the server level firewall are usually the provider's job. Your CMS, theme, plugins and admin passwords, on the other hand, are your job. Many attacks come in through outdated plugins or weak passwords, and in that case a new host will not solve anything.
So how do you measure it? Keep a short incident log: the date, the entry point if known, how fast the provider reacted and whether the problem came back after cleanup. Also check that your certificate renews properly with our SSL checker.
If incidents continue after you have cleaned and hardened your own side, or the provider cannot stop infections spreading from other accounts on the same server, then switching web hosting becomes a real option. For a broader view of common web application risks, see our OWASP Top 10 article.
Sign 7: Do you have real backup and restore guarantees?
Many plans advertise "automatic backups." The real question, however, is whether you can actually restore from them. If nobody has written down where backups live, how far back they go and who restores them in what time, you do not really have a guarantee.
The only honest test is a restore. Restore the latest backup to a test subdomain or a staging copy and record how long it takes. If restores cost extra, take days, or the backup sits on the same server as the site, treat that as a warning.
Ask your provider to answer these questions in writing:
- How often do you take backups, and how many days do you keep them?
- Do backups live somewhere other than the server that hosts the site?
- Can I restore a single file or only the database?
- Do restores cost extra, and how long do they take?
Even so, the provider's backup should never be your only safety net. Keep your own copy in a separate place. We explain the logic behind that in our website backup strategy guide.
Sign 8: How do you spot surprise price hikes and renewal traps?
The last sign is commercial, not technical. A tempting first year price can rise noticeably at renewal. In addition, the plan may quietly shrink, or a feature that used to be included may turn into a paid add on. That alone does not prove bad intent; still, it breaks your budget plan.
To spot it, put your invoices side by side. Write the introductory price, the renewal price and any changes to the plan contents in one table. Then read where the contract describes renewal terms, refund and cancellation windows, and whether a long term commitment locks you in.
Flexibility matters as well. Can you upgrade without downtime? Can you downgrade in the middle of a term? Are your domain, SSL certificate or email tied to the same provider? If the answers are mostly no, moving later will be harder.
We deliberately do not quote prices here, because they change by provider, currency and season. What matters for you is the ratio and the terms: the renewal gap, the lock in risk and the cost of leaving.
How can you summarize the eight warning signs in one table?
The table below puts each sign, its measurement method and your first move side by side. Fill it with your own records before you decide to switch web hosting.
| Sign | How to measure | What to look for | First move |
|---|---|---|---|
| Frequent downtime | External uptime monitoring | Contract percentage in minutes | Ticket with outage records |
| Slow site, high TTFB | Lighthouse and command line TTFB | web.dev thresholds, time of day pattern | Rule out the site first |
| Resource limits | Usage graphs in the panel | Hitting the ceiling at normal traffic | Reschedule jobs or upgrade |
| Outdated software | PHP selector and official support table | Branches without support | Test a current version in staging |
| Weak support | Ticket log | First reply and resolution time | Written escalation |
| Security incidents | Incident log, SSL check | Repeat after cleanup | Harden your side, then ask |
| No backup guarantee | Test restore | Time, cost, backup location | Set up your own backups |
| Price hikes, renewal traps | Invoice comparison | Renewal gap, lock in | Read the contract terms |
One sign alone is usually not enough to move. But when two or three signs show up together and keep repeating, you are at a real decision point.
Why is a cheaper looking plan not a good reason on its own?
This point sits outside the eight signs, yet it matters. "It is cheaper somewhere else" is not a strong reason to switch web hosting by itself. You have to weigh the price gap against migration time, possible downtime and SEO risk.
Cheap looking plans often come with these catches:
- A low monthly price that requires paying for a long term upfront.
- A noticeable increase at renewal.
- Backups, SSL or email billed separately.
- Resource limits that are not stated clearly.
For example, if you move to save a small monthly amount, the hours you spend on migration and one possible day of downtime can easily cancel the savings. On the other hand, if your current host shows none of the signs above, moving only for price is usually an unnecessary risk.
In other words, the right question is not "where is it cheaper?" but "what total cost gets me the same level of reliability?"
Should an online store read these signs differently?
Yes, because in ecommerce every minute of downtime hits carts and checkouts directly. On a brochure site, an hour of downtime is annoying. In a store on a campaign day, the same hour burns revenue and ad budget at once. Ad clicks keep coming, while visitors see an error page.
Therefore we suggest tighter thresholds for online stores. Monitor checkout and cart pages separately from the homepage; these pages usually run outside the page cache, so they reveal server weakness first. Also check your usage graphs before a busy season and see whether you hit the ceiling during the last campaign.
Support and backup signs weigh more heavily in a store, too. Order data changes every hour, so a daily backup is sometimes not enough. If you want to see how speed connects with sales, read our article on how site speed affects SEO. In short, store owners should take these signs seriously earlier.
Upgrade or switch web hosting: how does the decision tree work?
You have seen the signs. So what do you do now? The decision tree below lists the questions to ask in order, so you avoid an unnecessary move.
- Is the problem in your site? Check plugins, images and caching. If yes, fix the site first.
- Is it a lack of resources? If you hit limits at normal traffic, consider a bigger plan with the same provider.
- Does the upgrade solve it? Measure for two weeks after the upgrade. If the problem is gone, stay.
- Is it a quality or trust problem? A bigger plan rarely fixes downtime, support, security or backup issues. In that case, plan the move.
- Are the commercial terms acceptable? If you face renewal traps or lock in, plan an exit even without technical problems.
To upgrade without downtime, follow our hosting upgrade guide. In practice, the first two steps of the tree often remove the need to move at all.
How can you tell whether the host or your site is the problem?
Every decision stays half done without this split. A simple method is to test the server side and the application side separately.
First, create a blank or very light test page on the server, such as a plain HTML file. If that page also has a high time to first byte, the issue sits in the server, network or DNS. Then run the same test on your homepage. If the plain page is fast and the homepage is slow, the load comes from your application.
These checks make the split clearer:
- Turn off plugins one by one on a staging copy and watch TTFB.
- Make sure page caching and PHP opcode caching are on.
- Review heavy database queries with your developer.
- Check that DNS lookups are fast and consistent.
Application bottlenecks rarely disappear with a new host. In fact, a stronger server can only hide an inefficient plugin for a short time. So finish the diagnosis before you start any migration.
How do you build an evidence file for your current provider?
Giving your current host one fair chance before you leave is both reasonable and practical. However, give that chance with evidence. A clear, dated request gets results much faster than a vague complaint.
Your evidence file should include outage dates and durations from your uptime monitor, TTFB measurements from different times of day, screenshots of your usage graphs and the numbers of previous tickets. Keep each item short and dated.
When you send the request, ask a direct question: "What causes this issue, and by what date will you fix it?" That way, the provider's answer becomes measurable too. If no answer arrives, or the problem continues after that date, you know your decision rests on documents.
The same file also helps later with a new provider. You can tell them exactly which numbers you expect.
If you decide to switch web hosting, how do you plan the move?
Once the decision is clear, move with a plan, not in a panic. We only cover the outline here; for the full step by step list, use our checklist for changing web hosting without downtime.
The outline looks like this. First, open the new account and keep the old one running. Next, copy files, databases and email accounts. Then test the site on the new server through your hosts file or a temporary address before you touch DNS. Lowering the TTL of your DNS records ahead of the move helps the change spread faster.
After the DNS change, keep both servers running for a few days. That way, visitors or emails that still reach the old address are not lost. You can verify that records have updated with our DNS lookup tool.
Choose the date deliberately as well. Avoid campaigns, sales and peak seasons, and pick the day with the lowest traffic.
What should you watch on the SEO side when you change hosts?
If only the server changes while the domain and URL structure stay the same, the SEO risk is usually low. Still, do not skip a few checks, because a small mistake can affect crawling and indexing.
After the move, confirm the following:
- All pages return a 200 status code and no 5xx errors.
- robots.txt does not accidentally block the whole site.
- The SSL certificate is installed and valid on the new server.
- Redirects for www and https work exactly as before.
- Search Console shows no sudden spike in crawl errors.
If the domain, URL structure or platform also changes, the job gets bigger. In that case, also work through our website migration SEO checklist. That way, you will not miss steps such as the redirect map and ranking tracking.
How do you avoid repeating the same mistake with a new provider?
The most common mistake is escaping one host and landing with a similar one because of price alone. To prevent that, turn the eight signs above into a question list for the new provider.
Ask them directly. What is your uptime commitment, and what happens when you miss it? Are resource limits written down? Which PHP versions do you offer, and how often do you update them? What are your support channels and first response times? Where do backups live, and how does a restore work? What are the renewal price and cancellation terms?
Get the answers in writing. If there is a trial period or refund window, run your own measurements in the first weeks. For the full list of selection criteria, read our guide on how to choose web hosting.
Finally, define your needs honestly. A simple company site and a busy online store do not need the same plan. An oversized plan wastes money; an undersized one brings the same warning signs back within a few months.
Which tasks should you leave to your provider or a specialist?
To be honest, you should not try to solve every hosting problem yourself. On shared hosting, server software, operating system patches, hardware failures and network issues belong to the provider. Chasing those on your own mostly wastes time.
Likewise, if your business depends on email, do not migrate mailboxes by trial and error. A mistake in MX, SPF or DKIM records can mean days of lost messages. Plan those steps with the provider's migration team or an experienced specialist.
Measurement, record keeping and the final decision, on the other hand, should stay with you. If you run your own VPS, server security and updates are also your responsibility. If that load is too heavy, a managed hosting option may fit better.
Our team helps on the website side: speed, structure and SEO checks after a migration. If you are thinking about rebuilding your site, take a look at our web design service.
Quick checklist: where should you start today?
If you take one thing from this guide, let it be this: do not decide without measuring. Here is what you can start today:
- Set up an external uptime monitoring service.
- Measure TTFB for your homepage and one key inner page a few times a day.
- Check the usage graphs in your panel once a week.
- Compare your PHP version with the official support table.
- Log every support ticket with date and time.
- Restore one backup to a test environment.
- Read your last two invoices and the renewal terms in your contract.
After two to four weeks, you will have a clear picture. If the signs keep repeating, try an upgrade first. If that does not help, it is time to switch web hosting with a proper plan. That way, data makes the call, not gut feeling.
