Leaving SiteGround after 17 Days

I was excited to get Black Friday deals on two SiteGround accounts so I could finally get away from the hassles of managing my own Linux Virtual Private Server (VPS) for WordPress and other web sites. Unfortunately, the experience with SiteGround is more negative than positive. After less than a month, I’m moving off SiteGround and back to a VPS.

SiteGround has most of the basics one would hope for, and it does serve web pages. But issues with support and maintenance soon made it clear that it is not a good option for modest WordPress hosting.

Migration and Support Issues

The first issue was with SiteGround’s custom WordPress migration tool. It insisted on stripping the “www” subdomain from the site I was migrating. Chat support eventually escalated to ticket support. There, I emailed with five different reps. It seems you just get whoever is available at the moment—there is no consistency, no ownership. Some did not understand the issue. Some did not believe me until I uploaded screenshots showing the wp_options table in the database. The first rep asked if he could do a replace in the database to add back the www. I said no, I want to get the migration tool working because I have several updates to do. The fourth rep made the change without asking. Yep, just did a replace-all in my database without permission.

It became clear that I would need to develop my own migration workflow. I eventually migrated manually. With SSH access, and experience from previous migrations, this wasn’t too difficult. I cut over the DNS and it started serving web pages.

CPU Usage Mysteries

This is where the real worries began. The first account I worked on was for a single, small site, under 2GB of data and about 3MB in the database. I chose the StartUp plan, designed for a single site under 10GB. Perfect, right? What wasn’t immediately obvious is that this plan is severely limited in CPU usage. From the main comparison page, click for the detailed comparison page, then scroll down to Server Resources at the bottom, then next to Server, hover over the Essential link. Finally you will see the CPU limits:

SiteGround 01

But what does that mean? How much can you get done in 1000 seconds per hour? As it turns out, not much. On this very small site, on a typical day, I saw peaks over 1000 almost half the time.

SiteGround 02

Why? What is taking so much CPU? SiteGround does not permit access to Linux tools like “top”, so you can’t see which processes are consuming CPU. Support will not analyze usage for you. All they provide is a generic article about reducing usage by usage cache, removing unused plugins, etc.

It does seem that there are an unusually large number of fake logon attempts per their traffic log:  about 130,000 in just over two weeks. Why so high? Where are they coming from ? I installed the WordFence plugin to try to track them but found nowhere near that number of failures. And of course, WordFence itself uses CPU, so you can’t leave that running!

SiteGround 03

One thing that I expected to use a bit of CPU is my nightly cron job that uses tar to create a site backup. This they simply cut off every night, even after rate-limiting with “nice”, meaning I got less than half of my 1.7GB backup done every day:

SiteGround 04

As I searched for solutions to the CPU limit issue, I started to see many reports of similar issues. The first article raised an alarming possibility: if you go over your limit, they may just shut down your site for the rest of the month. You might be able to get a reprieve through support, but what if that happened during a live streaming event, for example?  They will supposedly email you when your site is getting close, but their automated emails were getting trapped in my Microsoft 365 quarantine, so I might not see the email for a day or so.

Okay, so how much have I used this month? How close am I to the 300,000 monthly limit? I could not find that figure on the dashboard. I thought, okay, I’ll check with support on that. During a 30-minute chat, I learned that, “Currently we do not have a tool that can show you the monthly quota.” So even support cannot determine how close you are to the limit. I finally went in to the daily history, hovered over each day, and copied the usage into a spreadsheet:

SiteGround 05

I discovered that in the 16 days from December 4 through December 19, the site had used 276,783 CPU seconds. Really? That’s 76 solid hours of computing in just over two weeks for one small web site.

SiteGround 06

Apparently I was a little over one day away from going over the limit, but I still had not received an 80% or 90% warning email. Maybe there some “grace extension”—the support rep said as much in chat—but that doesn’t help me to manage the site and plan for an upgrade if necessary.

Conclusion

Support is friendly but inconsistent and may make changes without permission. The error traffic and CPU numbers don’t seem plausible.  I can’t do my own backups. Most importantly, I can’t live with the prospect of a production web site being taken down at any time. I ported away from SiteGround on the 17th day. The new VPS running the site is using almost no CPU.

To their credit, SiteGround made the termination process painless. In a few clicks in the client area (ignoring the invitation to chat), I was able to cancel the service. I receive an email confirming the cancellation and, since it has been less than 30 days, promising a  refund.

Note I’m well aware that the hosting business is mostly driven by referrals. Authors earn $50 or $100 per account they refer. One prolific blogger posted a screenshot of his SiteGround affiliate dashboard showing over $391,000 in commissions paid out. Maybe I’m in the wrong business, but I’m choosing to post this with no affiliate links and ask that you keep them out of the comments.

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.

This site uses Akismet to reduce spam. Learn how your comment data is processed.