After the initial creation of a Jekyll blog, "managing an entire blog infrastructure" is insanely easy and low maintenance.
It's a static site, so you can host incredibly easily on any number of cloud services, from heroku to AWS S3/CloudFront, many (most?) people keep their Jekyll sites in a git repo (often github) so you won't lose data, and can easily shove it onto another server in no time at all.
Really, it's less maintenance than pretty much anything I've ever had online.
I don't think it's quite a simply answer like X% uptime.
A lot of the decision is the 'quality' of the downtime. For example:
* Is it generally stable, but only going down in peak load situations (obviously no good if you know peak load occurs when you are doing critical new product release/sales etc, but may be okay if you peak load corresponds to non-critical events).
* How long is the outages? If it goes down for 1 minute each day, that may be more acceptable compared to '100%' uptime except one day when it goes out for 365 minutes.
All of that affects the impact that the downtime has on your venture - it's quite possible you might have 'poor' uptime stats, but it has zero effect on your business, in which case the cost/effort savings from using a 'poorer uptime' hosted service may be worth it.
I think it's more important to know _when_ the downtime occurs vs. the percentage itself.
If the site is down from 12am to 6am due to some botched maintenance, I really don't care, as traffic will be minuscule, if not non-existent for our core market. And 6 hours of downtime is a killer for uptime percentage.
The "Jekyll is so easy! It's the easiest thing I've ever maintained!" argument reminds me of Andy Rubin's now infamous quote about the openness of Android: "the definition of open: "mkdir android ; cd android ; repo init -u it://android.git.kernel.org/platform/manifest.git ; repo sync ; make"
The point of Tumblr is I don't need to maintain _anything_!
