Strong SLAs are nice, but wouldn't the best measure be historical outages as a percentage of whole infrastructure uptime? For most application, receiving compensation for an SLA breach is negligible compared to the cost of an outage to the customer.
One hour of downtime for an application paying $20,000/month for cloud services is worth $27.78. Even with a 100x multiplier the customer would be due a check/credit for $2,778. Given the choice, I'm sure most rational businesses would prefer the uptime over the credit. Perhaps someone running a company with similar cloud service bills could chime in.
I'm not sure the best way to approach it. The issue is that there is (or can be) a huge imbalance between cost and impact for cloud service downtime. A business-critical application coming down for even an hour has the potential to cause significant heartache to the customer's business. The imbalance is so high that I'm not sure it's possible to justifiably compensate for your customer's business impact, based on what the market is for cloud services.
My thoughts on the matter are this:
* Nearly any compensation is "not enough" to a customer. They would have rather had the service not come down.
* It is nearly always better to use extravagant SLA breach compensation for higher redundancy. [1]
* Because 100% uptime is prohibitively expensive, transparency about historical uptime is vital for a prospect making a buying decision.
* The most fair way to compensate a customer for downtime is to take out an insurance policy against your service for the cost of downtime to your customer. (This is unique to each customer, and service should be priced accordingly.) [1]
1: Customers should be compensated for downtime, if at the very least because they aren't able to use the service they paid for. If additional money can't be used for additional redundancy/reliability, it can be used to insure against the cost of downtime.
Edit: After re-reading your question, I see that I misunderstood your question. I don't mean to say "Your customer was down for an hour, give them an hour (or more) for free." I actually meant "Your customer was down for an hour. That costs them $XX,XXX in headache. You can't expect to compensate them enough to cover that, so it would be better to avoid the downtime."
If an application is that business critical, then shouldn't the organisation be running it across multiple cloud providers, or ensuring it can run it internally?
One hour of downtime for an application paying $20,000/month for cloud services is worth $27.78. Even with a 100x multiplier the customer would be due a check/credit for $2,778. Given the choice, I'm sure most rational businesses would prefer the uptime over the credit. Perhaps someone running a company with similar cloud service bills could chime in.