Dreamhost has taken a lot of hits recently due to instability and downtime.  I think some of the complaints were overblown.  After all, if you’re betting your business on a website, a $9.99/month shared hosting plan isn’t very smart.

However, Dreamhost has slipped in several areas since I first joined them in 2000.  Given my recent experiences with them and their support staff, here are a few recommendations I have on ways Dreamhost could improve.

1.  Bring back targeted email/panel announcements.

This was one of the better things they used to do.  Whenever a server you were using was going to have any work done they’d send you an announcement telling you what servers were affected, what was being done, when the server would be down, and for how long.  They’ve since moved all of their announcements to their status page, which is a crappy way of doing things.

I don’t expect Dreamhost never to have any downtime, especially at the rates we’re paying.  But they could certainly do a better job of communicating with users.  As an example, they moved my server in early December and the only way I found out about it was after the fact when I saw their status entry.  I should not have to keep track of their blog to determine when one of my systems is being affected.  I should get a directly targeted email.  It cuts down on the clutter I have to manage.  Yes, I know they have RSS feeds, but that still means I have to poll the stupid thing to get information and that I have to wade through all the announcements that are meaningless to me to determine if something is relevant.

This would have also helped me with the ImageMagick issue that I discovered after the upgrade (i.e. I would have known the exact date of the change).

2.  Inform users when their particular systems are down or are rebooted

This is somewhat related to the first item, but that was proactive, while this is reactive.

It’s understood that sometimes things break and a system goes down or has to be rebooted (even if all of your stuff is still working).  As soon as any trouble ticket for a particular system is seen and the problem is verified (not fixed, just verified), then all users of that system should be notified that a problem has been identified and is being worked.  When the problem is fixed, another announcement should be made.  Being properly informed would likely prevent additional trouble tickets from other users of the system if they know the problem is being worked.

I think this would go a long way towards getting ahead of the customer satisfaction issues.  Something like 90% of the griping (my unscientific impression of it, anyway) in the comments is from people who are complaining that their sites are down, yet they aren’t affected by the system that was mentioned on the status page.  But since they don’t trust the ticket system and don’t have any positive information about the problem they flood the comments with complaints about their own sites.  If the system was known to work properly and people knew they’d be notified, there’d be a lot less griping. 

3.  Allow users to update their own trouble tickets

If there’s a way to do this, I haven’t found it.  But in several instances now I’ve need to update the ticket with new information (i.e. in one case I found the problem myself and just needed them to do something; in another the problem went away “on its own”).  My only recourse was to either open a new ticket and reference the first or wait for the tech to reply. 

The last case, where the problem went away on its own, appeared to me to have been a problem with the database server.  And from what I could see, someone rebooted it.  Everything was working fine within 30 minutes of me opening the ticket.  First, if I’d been properly informed (per my suggestions #1 and #2 above), I’d have understood what was going on (and obviously someone was working on it, since the DB system was rebooted), and would not have opened a ticket.  Or, if I hadn’t seen the announcement in time, I could have closed the ticket myself, thereby saving everyone time.  Instead I had to wait 14 hours for a Dreamhost tech to get around to telling me that the site was working fine now.  Duh! 

4.  Provide a site monitoring service

When I first started with them they used to have a system status page where you could see the uptime information for your Apache, MySQL, and SMTP/POP3 services.  Of course, checking uptime in Apache isn’t necessarily an accurate reflection of a site’s availability, since there are other factors, such as application load, network and database availability, etc that can allow Apache to stay up even if the site doesn’t “work.”  Since the status page didn’t give accurate uptime impressions, they decommissioned it.

It’d be nice if they had a site/application monitoring service that allowed you to specify your own webpage and the frequency of monitoring.  That way it could monitor a real example of your application (i.e. the page you specify would access the database and run the application code) and not just the HTTPD status.  The service would then notify you if the site didn’t respond or gave an error. 

Since this involves additional resources to handle, I could see this being a fee-based add-on.  Perhaps it could even include a feature to open a problem ticket automatically if certain events are triggered (this would likely require an extra fee, as well as some work on your part to identify the various failure modes). 

Anyhow, this is just a “nice to have” thing, not necessarily something that’d be required.

At the root of all of these is a simple idea:  Keep your customers informed.  If people have relevant, timely, and accurate information about their systems, there should be a lot less griping (or at least less confusion).