Ongoing support woes - 24hourwebhostingsupport.com needs to go out of business

Thankfully (or not) this time my woes are on behalf of a client. Because my readership is a little on the techie side, enjoy.

I’ve narrowed it down to a company which is based out of Canada (Ontario) called 24hourwebhostingsupport.com. They appear to be a 3rd party support company that a lot of hosts are using to provide tech support. The problem is that 24hourwebhostingsupport.com hires the most incompetent, illiterate people available. Here’s an exchange that I’m currently involved in (hasn’t been resolved yet). I’ll update it as more and more humorous responses are sent to me.

If you’re a hosting company, and considering switching over to using 24hourwebhostingsupport for your tech support, please don’t. I’ve already cancelled one hosting account with one host because of these clowns, and if the situation you’re about to read about doesn’t improve, chances are that I’ll be urging my client to switch hosts too.

Initial chat transcript:

Please briefly describe your issue:: Every couple of page loads, I’m receiving an error: “ODBC Error Code = S1000 (General error) [TCX][MyODBC]Lost connection to MySQL server during query”

Note that I’ve previously experienced the same error with a different host, and the message received was “MySQL server has gone away”. The cause of the problem is the same: the connect_timeout is set too low on the MySQL server (likely so that hosts can overload these machines without having to worry about the number of concurrent connections.

Artem: Hello. You have successfully connected to your technical services operator. Please wait one moment while I verify and review your information.
Jonathan Lane: Sure
Artem: Please specify the affected page
Jonathan Lane: I’m currently working on a page at /clients — but it’s an ODBC error, so it would affect any page that accesses the database
Jonathan Lane: It’s intermittent, but seems to be happening a lot this morning
Jonathan Lane: . Note: the chat program is crappy, so if I haven’t heard anything in ~5 minutes I just start typing punctuation
Artem: I do not see any clients page
Artem: Please guide me
Jonathan Lane: {client URL}/clients/
Artem: Can I get any login info?
Jonathan Lane: You shouldn’t need it. Even with an invalid login, it does a database query
Jonathan Lane: I just got the error again
Jonathan Lane: It’s intermittent, but it is happening quite often
Artem: I tried several times and it just renews the page, no errors at all. No even login failure
Jonathan Lane: The error that’s getting reported is that the server is losing the connection to the database server
At this point I figure out what’s causing the problem, not that Artem will actually be of any help
Jonathan Lane: Is the connect_timeout set to 15 seconds on the database server?

Jonathan Lane: Did that recently change?
Note: We’ve been using this host for some time and only recently have there been reports of these ODBC errors
Jonathan Lane: It didn’t used to happen, now after 15 seconds I get the error consistently.
Artem: I would like to open a ticket for our Tier-3 Technical team to look into this issue. I will need to give you the ticket reference number, so please hold on one moment while I create the ticket. Is that OK?

Jonathan Lane: Here’s a test case for you: {URL}
Jonathan Lane: Load the page, wait 16 seconds and reload it. You’ll get an error
Artem: Thank you for holding. The ticket number is {number}. You will be contacted on the e-mail address that you have specified once the issue is resolved.
Jonathan Lane: Okay, thanks. You got that test case?
Artem: Yes, I replicated your error message
Jonathan Lane: Excellent. Thanks for all your help.
Artem: You are welcome.

While not very helpful, Artem was polite and finally managed to see the error message. He opened a support ticket for me (for some bizarre reason, this host won’t let you open your own tickets). Later that day, I get an e-mail reply (my commentary paragraphs are in green, the e-mail messages are in black):

The e-mails start:

Thank you for contacting 24HourWebHosting Technical Support!

The ticket # {number} that was submitted for {domain}, regarding database slowness issue, has returned from our investigation. Our testing did not lead to the results you have provided in this ticket. We were able to connect to your database successfully and the test script is loading for 1-2 seconds:
{test case url}
This ticket is now closed. If the issue still persists in certain time periods please contact us back for testing. If you have any additional inquiries regarding the issue, please do not hesitate to contact us and we will be glad to assist you further.

Oh dear. Poor Artem made the issue sound like a database performance problem. That’s not right, clearly Tier-3 didn’t know what to look for. I replied with:

The problem wasn’t with slowness, it was that is you load the page, wait 16 seconds and then hit reload, you get an ODBC error.

I like to keep my messages short so as not to confuse/distract the people working support. Wouldn’t want them to waste time mesmerized by my poetic grace.

The latest reply just came in:

Thank you for contacting 24HourWebHosting Technical Support!

We have investigated your issue and found out that the database connection script used at {test case url} does not have the correct database details. For example, the username “{username}” does not exist on our system. The correct database connection details can be found in the Database Manager application located in the WebsiteOS. If the issue you reported persists after you correct the script, please contact us again providing your database connection details.

One thousand points goes to the team that can tell me what’s wrong with the logic in this reply. 3, 2, 1… Here we go! If the database details were wrong, the script should never connect. No? Oh, they’ve got one of those special servers that lets people connect with random usernames and passwords every second connection. I see. So clearly it’s not a problem with “my script”, it’s a problem with their server. Load the page (no errors). Wait 16 seconds. Push “reload/refresh” in your browser: ta-da! ODBC error! It’s like magic. Thank you folks, my next show will be in 16, 15, 14…

So here we are now. My last reply:

It connects just fine the first time, so the settings are fine.

Do this:
1. Load the test page (notice no error)
2. Wait 16 seconds
3. Press reload in your browser. Note the error message.

Feel free to repeat this over and over again. It will always give you an error the second time. If it were a problem with the settings used, it would have an error every time.

The funny thing is, I know exactly what the problem is, and I even know how to work around it. The work-around is to set up a cron job to curl a page that makes a database query every 14 seconds (keeping the connection open and alive). I’d prefer if they just fixed the server setting though.

I’ll keep you updated as I’m repeatedly told that it’s a problem with my script…

Latest update!!!

The ticket {number} that was submitted for {domain}, regarding database slowness issue, has returned from our investigation. It has been determined that provided file {test case} is not using our DSN or database. We do not control database which it is using. Please note that your domain has {other DSN} and {other DSN} DSNs for access datadases which are working fine. This ticket is now closed. If you have any additional inquiries regarding the issue, please do not hesitate to contact us and we will be glad to assist you further.

And yet the problem persists. Wait, didn’t they claim that this was the problem previously? Yeah, they did. Great, they’re at the point where they’re recycling answers because they’re so clueless.

Latest update 2!!!

I’m not going to copy and paste the messages anymore because they’ve just become so lame. The summary is that they told me the database settings were wrong (they weren’t), but I updated them anyways. Then they told me my script was wrong (it isn’t) and they sent me a sample script. I replied saying that their sample script produces the same error, and the last reply I got was that they couldn’t reproduce the problem (yeah, sure). Here’s a video I did this morning of the problem in action.