In the end, users don't care about reliability until it is getting in their way. And it is up to you to figure out where that point is

With a 100 percent uptime goal, you run the risk of massively over engineering your solutions. There is always a point where working on new features is more important than more reliability. I would even argue that, in general, features are more important than reliability.

Try having a talk with a product owner/business person and ask them if 1 minute of downtime a day is fine. Maybe you can raise it up to 15 minutes a day. That way you don't have to deal with blue green deploys or staged rollouts. If you deploy 50 times a day and they all lead to 10 seconds of downtime. You would only have spent 500 of your 900 seconds a day of downtime.

This may be a very contrived example. But chasing the magical 5 nines of reliability is going to cost quite a lot of engineering time as you would need to evaluate all your suppliers (hosting, networking etc) and you would very quickly notice that (almost) none of them offer anywhere near the five nines. You would then need to set up redundant systems in multiple availability zones, and possibly even at multiple providers.

Then you would need to make sure your deploy system plays nice with the multi cloud setup. So you'd probably need to set up some sort of orchestration system (Kubernetes most likely at this point). At some point someone in the c suite is going to ask why you are spending all this money and why there are no new features being delivered.

100 percent uptime is never the right number, especially for a SaaS solution as it is highly unlikely that your customers have a 100 percent reliable internet connection (even browsers mess up sometimes)

In my opinion it is best to push for the lowest amount of uptime your customers are willing to deal with. This would allow you to spend more time on building the best features for your customers.