Yeah, I've always encountered resistance when wanting to report accurate SLAs. I have found that typically SLAs are based on what the marketing team thinks sounds good, not what the technology can provide, so the goal is to hide outages and write legal documents that say "when we say uptime is guaranteed, what we mean is that we'll give you some insignificant amount of money when you're down for several days." So everything is legally in the clear, but customers assume some sort of reliability that doesn't exist. What this means is that it's a race to the bottom; if one company claims 100% uptime, the next company either has to explain why that's bullshit (and people react negatively to negativity, even when it's true), or do the same thing. The result is that everyone now has 100% uptime.
The problem with this model is that it doesn't allow engineering teams to set realistic goals to improve reliability. Because a customer being down for 3 days doesn't cost the company any money, you can't deploy expensive engineering resources to prevent that sort of thing from happening again. Meanwhile, if you track your SLA accurately, and compensate customers in a way that's commiserate with the inconvenience they experienced (something like "the entire month is free if we're down for 8 hours in a row"), then you can start doing real engineering. You have a clear number that shows where you're at now, and you have a goal for where you want to be, and you have a cost associated with that goal... suddenly you can make intelligent decisions about what to work on. This class of outage costs us $600,000 a year. It would take one engineer at $200,000 a year 3 months to fix it. There's $550,000 of free money. Instead of being a cost center, you're a profit center! And customers get a better product. How is that not a win? I'll never understand.
One thing I liked about working on Google Fiber back in the day is that US-based telephone support was not something that we would compromise on. It was expensive! So when we could eliminate classes of problems that people call in about, like poor WiFi connectivity or bad TV remote Bluetooth pairing, you could directly see the savings in support cost. You could spend a year debugging WiFi, and instead of looking like flushing money down the toilet, it looked like making money. It was a joy to work on. But obviously a very uncommon way of accounting. It's easier to say "everything is perfect, we dare you to cancel" than to invest in engineering. As an engineer, that's sad; we want the world to work better... but it's only possible with resources.