Rethinking Gmail: Reliability Matters

Gmail has changed the way we think about email, mostly for the better. Lately, though, Gmail has become notorious for its problems rather than speedy search and its "never delete mail again," storage allotments. It might be time for a tough love approach.

For better or worse, Gmail is one of the poster children for Web-based applications. Millions of people use Gmail to manage their email and depend on Google to provide reliable access to their mail. The problem is, Google has had a few high-profile outages that should be causing some concern about hosting anything mission critical with the Internet giant.

Another Day, Another Outage

This week, Gmail suffered yet another outage affecting an unknown (outside of Google, at least) number of users. This is hot on the heels of a massive outage that affected pretty much all Gmail users — including those of us who pay Google for the “Apps for your Domain” service.

Having worked in a data center, I have some sympathy for a company when there’s some downtime. Murphy’s Law can strike with a vengance, and I’m convinced that there is no such thing as enough redundancy to fully prevent service outages completely. What’s important is that those outages are minimal, managed well, and learned from.

Google may well be learning from its outages, and it seems to be managing them OK, but we’ve surpassed “minimal” at this point. The previous outage affected the entire service. This time, at least in my case, I was able to reach mail but unable to use my contacts and Gtalk became extremely unreliable.

Mail was available via IMAP and POP3, apparently, but isn’t the whole point being able to reach the service via the Web and have access to Gmail’s search capabilities? I’d be surprised if the majority of users have a client configured to access Gmail through IMAP or POP3.


When Google launched its “Apps for your Domain” service, with service level guarantees for $50 per year, per user, I was quick to move my mail from Tuffmail to Google Apps. The Gmail interface is vastly superior to other Webmail interfaces, and search is a key feature in the way I use email.

But it’s only superior if I can actually reach the service. For some users, it may be acceptable for email to be unavailable for an hour, or even a day. But for many use cases — like mine — email is mission critical. Having no way to access email for an hour can be a major problem in some cases.

You Get What You Pay For

The majority of Gmail users aren’t paying a cent for Gmail, so it’s easy to argue that they shouldn’t be looking a gift horse in the mouth. Or is it? It bears some careful thinking.

Google’s business model is dependent on happy users who continue to view, and occasionally click on, ads. Saying that the users aren’t paying is to discount the value that they bring to Google. If Google doesn’t keep those users happy, it risks losing them to a competing service and having less value for its advertisers.

To put it another way, Gmail’s users aren’t the customers, they’re the product and Gmail is simply a tool to harvest their attention on behalf of its advertisers. This is a symbiotic relationship so long as Google keeps up its end of the bargain by providing reliable services. So the argument that Gmail is “free” and that users shouldn’t complain about outages rings a bit hollow for me. Google needs its users as much, if not more, than the users need Google.


Migrating email providers is a headache. Doubly so when you maintain your own domain. Even so, Gmail’s recent problems have convinced me that it’s probably time to rethink using Google Apps as my primary mail service.

I’ve no doubt that one of these days, Google will be able to scale its service and provide more robust uptimes to its customers. In general, I think that Web based services will continue to approach “fat” client reliability. But we haven’t reached that state just yet. in the meantime, if email is something you depend on, Gmail may not yet be ready.

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62