A Cautionary Tale of Hosting
When last we left our hero, he was transitioning to a new web host. Shrouded in mystery as this event was, I'm sure many of you have been asking yourself: “But why is he changing hosts? What could it all mean?” Well, I'm glad you presumably asked!
First, the summary. (Spoiler alert!)
For anyone finding this post while researching Jumpline/DigitalSpace to try to decide whether to use them for hosting, here's my condensed Jumpline review (based on several year with two domains hosted on the starter plan): Jumpline sucks (presumed motto: ‘As little support as we think we can get away with, if that’). On three separate occasions Jumpline staff actively caused the majority of my site to stop working, twice through negligence. Not one of the support tickets I filed ended with what I would consider to be a satisfactory resolution, and even when the problems were very, very obviously their fault the responses I got were generally a mixture of lack of interest in the causes, and attempts to shift blame to me. A ticket filed about ongoing email loss took almost a full day to get the first (unhelpful) reply, and more five days to get a second (totally useless) response.
My overall impression is that support's primary role is to close tickets as quickly as possible, with investigating and fixing problems a distant second, and common-sense customer service (e.g., apologizing when they make serious mistakes) not even on the radar.
And as an added bonus, I just discovered that they categorically refuse to provide pro-rated refunds on the remained of annually-paid hosting, even if the reason for closure is their own repeated negligence.
If anyone from Jumpline reads this, spare me a defensive reply that explains how my unvaryingly poor support experience was actually my own fault. If you feel the urge to write one, take that energy and instead apply it to figuring out what you should be doing differently so that people don't have experiences like mine.
And now, the very long rant version.
Since escapedthoughts.com's inception, it had been hosted by DigitalSpace, which was a cheap but developer-friendly (shell access, lots of supported scripting languages, etc.) hosting company recommended by a co-worker, and for quite a while everything was great. Then, one fateful day about two years ago, I received an email with “exciting news”! Yay! DigitalSpace was being acquired by Jumpline. We were all assured that the transition would be smooth and easy, and there was nothing to worry about.
This turned out to be code for “we will break everything”. I woke up one morning, and escapedthoughts pretty much didn't do anything any more. I ssh'd in to look around and see what had changed, and discovered that I didn't have the ability to read or write to my own home directory. Huh. One exchange with support later I could read my home directory (but not write to it—this turned out to be a permanent, intentional “feature” of the transition that was supposed to be so smooth I wouldn't even notice), so I set about trying to assess damage.
Well, it didn't take long to figure out why my site (mostly a motley collection of python, ruby, and perl scripts) didn't work:
$ irb
bash: irb: command not found
$ ruby
bash: ruby: command not found
$ which ruby
bash: which: command not found
$ find . -name ruby
bash: find: command not found
$ perl
bash: perl: command not found
$ python
bash: python: command not found
$ chmod
bash: chmod: command not found
[...]
In migrating my mostly-script-based site to their new and improved machines, they remove all access to all the scripting language interpreters (what could go wrong?), and pretty much everything else for good measure. Support ticket number two, which included the above output, got me access to most things. But not ruby, because apparently the fact that half the transcript of commands was me trying to figure out where the hell ruby had gone wasn't enough of a clue that I'd like ruby access thank you very much. Total number of support tickets before I could even start figuring out all the other ways my site was broken: three.
Yes, my smooth and painless transition was off to a great start. It took me the better part of a weekend to go through and fix all my scripts, which had been further broken by the changes they made to their directory structure.
I'm a big enough man to admit my mistakes, and at this point I made a big one; as a result I share the blame for everything that follows. When I saw what a complete Charlie Foxtrot they made of the transition, I should have gotten out immediately, but instead I gave them the benefit of the doubt. I chose to believe that in less stressful and turbulent times they would surely be more competent.
And things did settle down for a while. It was over half a year before they totally broke my site again—shortly after I decided that they were all right after all, and added a second domain with them. It turned out that one of their admins had moved the script that powers this blog into a “disabled” folder four days earlier (yes yes, insert joke about me neglecting my blog here), and didn't bother to tell me. Naturally the reply to my support ticket (summary: ‘OMG, WTF?’) was profusely apologetic.
Ha ha. No. I was told that my script was using too much CPU, and had to be disabled, followed up with: “Please note that if your account does continue to consume enough CPU that other customers service is impacted, the account could be suspended or deleted without warning”. To be fair to them, I do understand that on shared hosting they have to act quickly if my mistake is messing with other hosted accounts, so not getting advance warning is understandable. Less understandable was the fact that in four days they couldn't manage to email me a heads-up that they crippled my site, and that their reply to my ticket totally ignored the (very explicit) question about why, exactly, that was. When I asked again, this was the helpful reply: “Typically we do notify the user when a script is moved or disabled. Usually before we move it unless it is an emergency.”
No apology, no explanation. Apparently I was supposed to be mollified by the fact that they have a policy of telling people about changes like this, despite the fact that they totally failed to follow it in my case.
I made some changes to the blog software that I expected to reduce CPU use, then set about trying to find out how much I was using, so I could make sure my account wouldn't be deleted without warning—it was clear that whatever their faults, they were good at this “without warning” thing, so I took the threat seriously. Turns out (you guessed it, another support ticket!), you can't find out what your CPU usage is. And they won't say what the limit is. I just had to accept that if a number that I couldn't measure went over a number I didn't know, I would be shut down and all my content deleted. Nice. When I pointed out that this was perhaps not entirely fair, they assured me they would let me know in advance were there any further problems.
Filled with confidence, I made very sure that I was doing regular backups of my site.
A few months later, I asked them to turn on the web stats that their documentation claimed was available but wasn't. Apparently, it required .htaccess settings, and instead of adding them to my existing file, they just destroyed mine and replaced it with theirs. I bet you can guess what effect that had!
This time, I noticed that everything was totally broken the same day, and thanks to my backups it was easy to fix. The response to my support ticket (summary: ‘OMG, WTF? You need to fix your system so it doesn't delete user content.’), in its entirety:
“It is strongly recommended that anytime you make custom changes to .htaccess that you back it up everytime you do so to prevent such issues from occuring. We have never heard of the webstats program overwriting an .htaccess file but we will keep our eye out for similar issues with our customers.”
So instead of an apology, I got 'You should assume that we will delete files without warning. Oh, and I think you just made this up.' Because blaming the customer for your own mistakes is always a winning support strategy. (Note also the misspelling of ‘let you fix our mistakes after you notice that we've broken your site’ as “prevent such issues from occuring”.) By now it's really obvious that I should change hosts, but finding a host that does what I wanted and wasn't way more expensive was not so easy, and reviews for the ones I found were mixed. Gambling with going through the pain of switching when I might be as worse off afterward didn't appeal to me, so I gritted my teeth and decided to give them one more try.
Fast forward a year (a whole year without incident—unprecedented!) to the end of last month, when I hear that email sent to a couple of forwarders on the other domain just weren't showing up any more. I try this out with my addresses there (webmaster@ as a full email account, and admin@ as a forwarder to webmaster@), and sure enough, in two tests an hour apart, the messages to the forwarder just vanished while the ones to the full account work fine. This was perfect, because they couldn't just hand-wave it away as being a problem with whatever mail system the forwarder was sending to; it was all within their own severs. I wrote up a detailed ticket, explaining that a) this was a general problem affecting multiple forwarders, and b) I had a very simple, reproducible test case using the admin@ address. It took a full day for them to answer, even though it was clearly a serious issue (although l was working under the assumption that they would continue to be made of fail, and converted the other forwarders to full accounts while I waited so that no more important mail would be lost). Again, their entire reply:
“The admin redirect should be working for you now. I am not sure what got modified on it, but I ended up deleting it, and recreating it to get it to work. I was then able to send 6 test messages in a row to your account, and all were forwarded.”
I wish I were making this up, I really do. Their solution to a general problem was to destroy the test case without investigation, and close the ticket. When I reopened it to ask what they had done to fix the underlying problem, it took them only five short days to write back to say, basically ‘Nothing; we don't know what happened. Do they work now?’
A series of exchanges ensued, with me getting increasingly irate. Highlights from their replies include:
- “We cannot duplicate your problem. Do you have any specific details about your problem?” (‘Even though you handed us a test on a silver platter and we destroyed it, it's your fault we can't investigate this.’)
- “We are not getting any other complaints from other customer's [sic] and the server logs do not show any issues with email” (‘We don't know what happened, so we're going to assume you are making this up.’)
And then, my personal favorite, when I asked them in the clearest terms I possibly could how they expected me to use the forwarders again when they couldn't explain a spontaneous, nearly domain-wide failure.
- “I feel very confident it will not happen again because we have several thousand clients and this issue was not reported by anyone else.” (‘The same conditions that didn't prevent a failure before will definitely prevent one in the future.’)
It seems that the mission of Jumpline support is to explain how all failures are figments of my imagination and/or my fault. Their ongoing lack of interest in understanding why their processes or systems failed so that they can actually fix them just boggles my mind. I can't tell if they truly believe that they are infallible, and thus the best way to keep customers happy is to convince them of the happy truth that Jumpline never made a mistake in the first place, or if they just don't have any interest in customer service.
Category: Geek