The previous responses to this comment are spot on. I would add two things: (1) When you write an app that relies on a cloud service and your app has trouble, you have to make the choice to either dig into your app or call the cloud vendor for help. If you make the wrong choice, you lose precious time in the resolution process. This data makes that triage process simple. If your indicators and the GCP service's indicators go bad at the same time, call Google. If the Google indicators look good and yours are struggling, look at your app. (2) When you do call tech support from a service provider, there is often some back and forth to show that it is the service provider that is causing the issue. With this data, that back and forth goes way down. Show them the chart that illustrates the Google service level drop and everyone agrees on the data and support can jump right on the issue.
One can object saying, "Shouldn't the cloud vendor already know that there is a problem and just fix it and let me know?" That is true for the infrequent big things. But, for the smaller, but more frequent issues, there is a specific issue for some method in some service for some customers in some region, etc... When that happens, the few customers who are hit by that issue can have a hard time knowing it's happening because it does not show on the global dashboard and then have a hard time getting tech support to see that this is really a change in service for them. This data solves those issues.