... and yet I've seen CloudFlare cache fail many times (like a couple days ago, a story on HN front page about airplane bathrooms having ashtrays: http://news.ycombinator.com/item?id=4005906).

Still a great service though, they would be big someday.

I don't think it's a CloudFlare issue. Rather, people set up CloudFlare and don't properly configure it. Hence, CloudFlare passes most of the requests on directly (no caching-only rules), server goes down, and then the cached pages expire because they didn't configure the cache expiry dates on their web server.

In my case (the bathroom ashtrays), Cloudflare hadn't had time to cache the HTML part (they normally only cache the static content, then later suck in the dynamic part to serve in the event of failure).

After I set up a page rule to explicitly cache and serve the entirety of the bathrooms page, things went very well. Or at least I could serve a lot more people.

My blog is hosted on a $20/mo VPS and is definitely not set up to serve that many people at one time. If I had been using a blog software that was more lightweight and where the front page wasn't nearly as large, and I was using static html files, then it would have been better, but it wasn't ever going to be great.

Glad to hear the "cache everything" PageRule did the trick to help out with serving the HTML content. We are hesitant to make that a more prominent option though because caching the HTML can lead to security issues on dynamic sites (or forms that gather any kind of data). It certainly can help tremendously though for high volumes of traffic as long as the caveats are considered as well.

When Cloudflare has a high-profile client, they'll often blog about it. It's a smart marketing technique, because they lift on the publicity around the client.

True, but the most important thing is that it worked.

This scenario is actually daunting for most small sites: it's four days out, you're about to get tons of traffic, and keep it to yourself :)

Setting up Google-load-capable infrastructure in 4 days is trivial for some you on hackernews, but non-trivial for others.

Cloudflare sounds like a convenient, drop-in solution for when you don't know how to configuring your own reverse-proxy.

Cloudflare is much, much more than a reverse-proxy. It is more comparable to Contendo (now part of Akamai), but Contendo charged thousands for what CloudFlare does for free.

I'm happy to hear that CloudFare was able to help out in this situation.

I am especially happy because I came to know CloudFare not through HN, but through constantly seeing their failed cache page.

Edit: That sounds really brash, but I sincerely do mean that they have lots of clients that I frequent and if their reliability improves, it will prove to be very valuable.

Just as a note -- a site offline page indicates a back end origin server issue in the vast majority of instances. That wouldn't be short coming of CloudFlare though if the back end web server is having issues.

I'm very happy with my experiences with CloudFlare.

My blog has failed several times under load, despite cloudflare being in front of it, but at no time was it a lacking of cloudflare. It's that they are performing a CDN service which proxies the request for dynamic data back to the source (which in my case is the majority of the load, since my blog is very image-light).

Once I set up cloudflare to aggressively cache and serve a page under load, the weight on my blog's VPS was better (the load was down from 70 on a 2-core machine, and the I/O wait dropped from 95%).

Cloudflare does what they do very well, and their CEO (http://twitter.com/EastDakota) is very, very responsive to requests for help.

I'm glad I'm using cloudflare.