4 ms·
Uptime % includes time to recovery. Since you're not up if you're still recovering...
by acchow 9y ago
Uptime % includes time to recovery. Since you're not up if you're still recovering...
- hkmurakami 9y agoYes. And recovery time should be tracked separately from uptime is the takeaway imo.
- ram_rar 9y agoBut that still does not provide much inside into recovery time. Its good to know, the median recovery time.
- solatic 9y agoThe only time that uptime would not give insight* into recovery time is if the service is not being regularly updated (remember, zero-downtime deployments should never affect your uptime numbers), then, the uptime numbers improve over time to something really impressive but go in the toilet once the shit hits the fan. I hardly think it's reasonable to consider services like GitHub or infrastructure like AWS as being irregularly updated...
- OJFord 9y agoI think GP's point is that you should assume the 0.{however many 0s}1% it's down is going to be a bad time for you, and then ask yourself how long you want to wait to be back up. A long down time might be worse for you than a shorter down time more frequently.
- paulddraper 9y agoI fail to see how. 99.99999999% uptime is 3 milliseconds of downtime a year. That's not even a TCP retransmission.
- OJFord 9y agoWell for a start, ten nines is a lot, isn't it? If this service is up for five years, then it can go down for 15ms and still claim all ten over that period. Which is almost nothing still, but if you needed ten to begin with then maybe it's quite a lot for you. All I'm saying is - and I think this is what the commenter originally twice above me meant - is that the rate doesn't give you all the information, you at least need a period as well.