Changed Hosting

I dumped my old hosting provider, PagePlanet, in favor of Hosting Matters because I was treated rudely by tech support. This change should have been completely transparent to everyone.

My first clue that something was wrong was intermittent trouble with FTP. This meant that sometimes I was unable to update my blog for several hours and caused me to delay a few articles. I could log in to FTP, but couldn't transfer files. Tech support consistently claimed it was something on my end, despite the fact that I blog from a Red Hat Linux 7.0 system that hasn't had any significant software updates since 2001.

My first report of trouble — in February 2004 — was dismissed when I said that FTP worked fine on a different computer. They ignored the fact that the problem mysteriously disappeared later with no software change (not even a reboot) on my end, and that the trouble was correlated with unusual error messages transmitted by their FTP software. "Customer service that just blows off legitimate and serious complaints is not doing the customer a service."

The problem recurred in August. And again in December. And again in April 2005. This time tech support discovered (shock!) that something was wrong, and I learned this:

We changed the FTP server because the one we were using had a memory leak that was causing slowdowns on the machine. The current FTP software is what we have been using on all 5 of the other web servers.

And shortly thereafter, they added:

Just wanted to let you know that we are going to be changing the hardware on the machine that you were having trouble FTP'ing to yesterday (arbyte.us). The hardware is apparently interacting with the FTP server causing the need for the active/passive setting change (software is the same and works fine on all other servers). If your client changed their active/passive settings, they might need to change them again during the next login.

The active/passive thing was bogus. But after they performed this mysterious hardware change, the FTP problem went away permanently. I was finally happy. (Not to mention vindicated.)

I was happy until January 16^th, when I noticed that my blog was down over lunchtime. At this point you need to know that my sister has a web design and hosting business and that I set up my blog as a client of hers, so she's my link to technical support. (She's really good — all the sites she designed look great; this one's ugly because I didn't let her make it pretty.) I sent my sister this note:

What's going on right now at the server? I can't load my blog. It tries a little — it starts loading the page, extreeeemely slowly — but it gives up. Everything else on the internet is working fine.

I need reliability!

That evening I sent her the following sitemeter graph that illustrates the outage. I grabbed the image around 9:00PM, so there's no data after that time:

Usually my traffic is fairly level throughout the workday, so it appears that service degraded gradually over the morning and failed completely over lunchtime. Things were back to normal by 2:00 that afternoon.

My sister contacted tech support on my behalf (accidentally stating Sunday instead of Saturday for the outage; but as you'll see this didn't matter) and got the following Shocking! Outrageous! reply:

I don't know if this will be a routine problem since there is no problem with the server. Nor was there a problem on Sunday beyond possibly a routine reboot in the middle of the night that would have lasted perhaps 90 seconds. The problem most likely is that his level one ISP provider is having problems talking to our level one ISP provider at the peering point. There is absolutely nothing either of us can do about that and it will eventually clear up by itself. The web server he is on has not had a down state of more than that routine 90 seconds or so for untold months now. Nor have we had problems with our local telco or its connectivity.

And if he wants to continue to blame us in a knee-jerk reaction everytime something glitches that neither of us have any control over I would suggest that he host somewhere else since I am in no mood to be accused of shoddy service by someone who obviously has no clue about how the internet works or where its fundemental [sic] problems lie.

By the way, has he ever even stopped to consider that his logging program generating that graph had a glitch in it and could not itself reach our server properly?

I was livid. This is tech support at its most arrogant and customer hostile. This kind of response is totally unacceptable. The message was sent with the following attachment, which tech support believed absolved them of any culpability (my blog was formerly hosted on the indicated machine):

I wrote back to my sister:

Who's this ill-mannered tech support person? I ask what's more likely: that the downtime was at the web host, or that there were two simultaneous outages affecting BOTH my local area AND sitemeter? I personally couldn't load my website over lunch. And if sitemeter didn't record any hits, that means nobody else could, either. I'd be tremendously surprised if sitemeter is geographically based in Portland, Oregon.

Is this the same tech support person who always said there was no trouble with the FTP service, until the trouble went away when they changed some hardware?

Here's some more grist for tech support. During the outage I *was* able to get an HTTP connection and download a small amount of data. The problem was that it always stopped well before loading the entire page. If his testing program stops shortly after connecting and doesn't try to download anything substantial, I'm completely unsurprised that it didn't notice any downtime. In validation parlance, their testing has a coverage hole.

This is outrageously bad support. Insulting the customer is a definite no-no, and they've convinced me to change hosts. They do not care about making their customers happy. If they don't want my business — fine!

Sitemeter works by logging traffic generated from an image link on the web page. I place it at the very bottom of my pages. That means that sitemeter will only record a hit if the entire page is transmitted. If it begins to transmit but doesn't complete — i.e., exactly the behavior I was experiencing over lunch — it won't record a hit, because the client's web browser never reaches the point in my source file that loads the sitemeter image.

The sitemeter server that I connect to appears to be geographically located in Florida. I'm in Oregon. This rules out the hypothesized trouble at a peering point involving my local ISP.

PagePlanet tech support gave me (1) an obviously wrong explanation and (2) attitude. So they're fired. Tech support needs to be like this if you want my business.