We're seeing some stuff is up, and some stuff is down and some of the stuff that was up a little while is down now. It's getting worse as of 9:53 AM CST.
You can get new tokens. Image pulling times out after ~30s, which tells me that maybe ECR is actually up, but it can't verify the caller's credentials or access image metadata from some other internal service. It's probably something low level that crashed, taking down anything built above it.
Actually, images that do not exist will return the appropriate error within a few seconds, so it's really timing out when talking to the storage layer or similar.
When they have too much pride in an all-green dash, sure. Allowing any engineer to declare a problem when first detected? Not so hard, but it doesn't make you look good if you have an ultra-twitchy finger. They have the balance badly wrong at the moment though.
A trigger-happy status page gives realtime feedback for anyone doing a DoS attack. Even if you published that information publicly you would probably want it on a significant delay.
I don't see why they couldn't provide an error rate graph like Reddit[0] or simply make services yellow saying "increased error rate detected, investigating..."
A executive has a OKR around uptime and a automated system prevents him or her from having control over the messaging. Therefore any effort to create one is squashed, leaving the people requesting it confused as to why and left without any explanation. Oldest story in the book.
Because Amazon has $$$$$ in their SLOs, and it costs them through the nose every minute they're down in payments made to customers and fees refunded. I trust them and most companies not to be outright fraudulent (although I'm sure some are), but it's totally understandable they'd be reticent to push the "Downtime Alert/Cost Us a Ton of Money" button until they're sure something serious is happening.
Oh, you can get pretty weaselly about what “down” means. If there is “just” an S3 issue, are all the various services which are still “available” but throwing an elevated number of errors because of their own internal dependency on S3 actually down or just “degraded?” You have to spin up the hair-splitting apparatus early in the incident to try to keep clear of the post-mortem party. :D
It should be costing them trust not to push it when they should though. A trustworthy company will err on the side of pushing it. AWS is a near-monopoly, so their unprofessional business practices have still yet to cost them.
> It should be costing them trust not to push it when they should though.
This is what Amazon, the startup, understood.
Step 1: Always make it right and make the customer happy, even if it hurts in $.
Step 2: If you find you're losing too much money over a particular issue, fix the issue.
Amazon, one of the world's largest companies, seems to have forgotten that the risk of not reporting accurately isn't money, but breaking the feedback chain. Once you start gaming metrics, no leaders know what's really important to work on internally, because no leaders know what the actual issues are. It's late Soviet Union in a nutshell. If everyone is gaming the system at all levels, then eventually the ability to objectively execute decreases, because effort is misallocated due to misunderstanding.
This is an incentive to dishonesty, leading to fraudulent payments and false advertising of uptime to potential customers.
Hopefully it results in a class action lawsuit for enough money that Amazon decides that an automated system is better than trying to supply human judgement.
Can someone just have a site ping all the GET endpoints on the AWS API? That is very far from "automating [their entire] system" but it's better than what they're doing.
The more transparency you give; the harder it is to control the narrative. They have a general reputation for reliability; and exposing just how many actual errors/failures there are (that generally don't effect a large swath of users/usecases) would do hurt that reputation for minimal gain.
I wonder how often outages really happen. The official page is nonsense, of course, and we only collectively notice when the outage is big enough that lots of us are affected. On AWS, I see about a 3:1 ratio of "bump in the night" outages (quickly resolved, little corroboration) to mega too-big-to-hide outages. Does that mirror others' experiences?
If you count any time AWS is having a problem that impacts our production workloads then I think it's about 5:1. Dealing with "AWS is down" outages are easy because I can just sit back and grab some popcorn, it's the "dammit I know this is AWS's fault" outages that are a PITA because you count yourself lucky to even get a report in your personalized dashboard.
It’s hard to measure what five-9 is because you have to wait around until a 0.00001 occurs. Incentivizing post-mortems are absolutely critical in this case.
Makes you wonder if they have to manually update the page when outages occur. That'd be a pretty bad way to go, so I'd hope not. Maybe the code to automatically update the page is in us-east-1? :)
Something like that has impacted the status page in the past. There was a severe Kinesis outage last year (https://aws.amazon.com/message/11201/), and they couldn't update the service dashboard for quite a while because their tool to do manage the service dashboard lives in us-east-1 and depends on Kinesis.
From what I've heard it's mostly true. Not only the CEO but a few SVPs can approve it, but yes a human must approve the update and it must be a high level exec.
Part of the reason is because their SLAs are based on that dashboard, and that dashboard going red has a financial cost to AWS, so like any financial cost, it needs approval.
It's not really dishonest though because there is nuance. Most everything in EC2 is still working it seems, just the console is down. So is it really down? It should probably be yellow but not red.
if you cannot access the control plane to create or destroy resources, it is down (partial availability). The jobs that are running are basically zombies.
The API is NOT working -- it may not have been listed on the service health dashboard when you posted that, but it is now. We haven't been able to launch an instance at all, and we are continuously trying. We can't even start existing instances.
I'm right in the middle of an AWS-run training and we literally can't run the exercises because of this.
let me repeat that: my AWS trainign that is run by AWS that I pay AWS for isn't working, because AWS is having control plane (or other) issues. This is several hours after the initial incident. We're doing training in us-west-2, but the identity service and other components run in us-east-1.
I’m running EKS in us-west-2. My pods use a role ARN and identity token file to get temporary credentials via STS. STS can’t return credentials right now. So my EKS cluster is “down” in the sense that I can’t bring up new pods. I only noticed because an auto-scaling event failed.
Heroku is currently having major problems. My stuff is still up, but I can't deploy any new versions. Heroku runs their stuff on AWS. I have heard reports of other companies who run on AWS also having degarded service and outages.
i'd say when other companies who run their infrastruture on AWS are going out, it's hard to argue it's not a real outage.
But AWS status _has_ changed to yellow at this point. Probably heroku could be completely down because of an AWS problem, and AWS status would still not show red. But at least yellow tells us there's a problem, the distinction between yellow and red probably only matters at this point to lawyers arguing about the AWS SLA, the rest of us know yellow means "problems", red will never be seen, and green means "maybe problems anyway".
I believe the entire us-east-1 could be entirely missing, and they'd still only put a yellow not a red on status page. After all, the other regions are all fine, right?
Zero directly-attributable, calculable-at-time-of-decision cost. Of course there's a cost in terms of customers who leave because of the dishonest practice, but, who knows how many people that'll be? Out of the customers who left after the outage, who knows whether they left due to not communicating status promptly and honestly or whether it was for some other reason?
Versus, if a company has X SLA contracts signed, that point to Y reimbursement for being out for Z minutes, so it's easily calculable.
Taken literally what you are saying is the service could be down and an executive could override that, preventing them for paying customers for a service outage, even if the service did have an outage and the customer could prove it (screenshots, metrics from other cloud providers, many different folks see it).
I'm sure there is some subtlety to this, but it does mean that large corps with influence should be talking to AWS to ensure that status information corresponds with actual service outages.
I have no inside knowledge or anything but it seems like there are a lot of scenarios with degraded performance where people could argue about whether it really constitutes an outage.
Yep. I was an SRE who worked at Google and also launched a product on Google Cloud. We had these arguments all the time, and the contract language often provides a way for the provider to weasel out.
One time gcp argued that since they did return 404s on gcs for a few hours that wasn’t an uptime/latency sla violation so we were not entitled to refund (tho they refunded us anyway)
Opex > Capex. If companies thought about long term, yes they might consider it. But unless the cloud providers fuck up really badly, they're ok to take the heat occasionally and tolerate a bit of nonsense.
This is no longer a partial outage. The status page reports elevated API error rates, DynamoDB issues, EC2 API error rates, and my company's monitoring is significantly affected (IE, our IT folks can't tell us what isn't working) and my AWS training class isn't working either.
If this needed a CEO to eventually get around to pressing a button that said "show users the actual information about a problem" that reflects poorly on amazon.
My friend works at a telemetry company for monitoring and they are working on alerting customers of cloud service outages before the cloud providers since the providers like to sit on their hands for a while (presumably to try and fix it before anyone notices).
I wonder how well known this is. You'd think it would be hard to hire ethical engineers with such a scheme in place and yet they have tens of thousands.
Because "uptime" and "nines" became a marketing term. Simple as that. But the problem is that any public-facing measure of availability becomes a defacto marketing term.
The older I get the more I hate marketers. The whole field stands on the back of war-time propaganda research and it sure feels like it's the cause of so much rot in society.
Also 4-5 nines is virtually impossible for complex systems, so the sort of responsible people who could make 3 nines true begin to check out, and now you've getting most of your info from the delusional, and you're lucky if you manage 2 objective nines.
That's why your status page should be completely independent from the services it is monitoring (minus maybe something that automatically updates it). We use a third party to host our status page specifically so that we can update it even if all our systems are down.
> AWS Management Console Home page is currently unavailable.
> You can monitor status on the AWS Service Health Dashboard.
"AWS Service Health Dashboard" is a link to status.aws.amazon.com... which is ALL GREEN. So... thanks for the suggestion?
At this point the AWS service health dashboard is kind of famous for always been green isn't it? It's a joke to it's users. Do the folks who work on the relevant AWS internal team(s) know this, and just not have the resources to do anything about it, or what? If it's a harder problem than you'd think for interesting technical reasons, that'd be interesting to hear about.
I think it's pretty unlikely that both Google and Facebook are affected by this minor AWS outage, whatever DownDetector says. I even did a spot check on some of the smaller websites they report as "down", like canva.com, and didn't see any issues.
I wonder if the other parts of Amazon do this. Like their inventory system thinks something is in stock, but people can't find it in the warehouse, do they just simply not send it to you and hope you don't notice? AWS's culture sounds super broken.
My favorite status page, though, is Slack's. You can read an article in the New York Times about how Slack was down for most of a day, and the status page is just like "some percentage of users experienced minor connectivity issues". "Some percentage" is code for "100%" and "minor" is code for "total". Good try.
There was a great response in r/relationship advice the other day where someone said that OP's partner forced a fight because they're planning to cheat on them, reconcile, and then will 'trickle out the truth' over the next 6 months. I'm stealing that phrase.
I assume each service has its own health check that checks the service is accessible from an internal location, thus most are green. However, when Service A requires Service B to do work, but Service B is down, a simple access check on Service A clearly doesn't give a good representation of uptime.
So what's a good health check actually report these days? Is it just about its own status, or should it include a breakdown of the status of external dependencies as part of its folded up status?
No wonder IMDB <https://www.imdb.com/> is down (returning 503). Sad that Amazon engineers don't implement what they teach their customers -- designing fault-tolerant and highly available systems.
When I worked there it required the signoff of both your VP-level executive and the comms team to update the status page. I do not believe I ever received said signoff before the issues were resolved.
It's funny that the first place I go to learn about the outage is Hacker News and not https://status.aws.amazon.com/ (it's still reports everything to be "operating normally"...)
I always got the impression that downdetector worked by logging the number of times they get a hit for a particular service and using that as a heuristic to determine if something is down. If so, that's brilliant.
I think it's a bit simpler for AWS- there's a big red "I have a problem with AWS" button on that page. You click it, tell it what your problem is, and it logs a report. Unless that's what you were driving at and I missed it, it's early. Too early for AWS to be down :(
Some 3600 people have hit that button in the last ~15 minutes.
When Facebook's properties all went down in October, people were saying that AT&T and other cell phone carriers were also down - because they couldn't connect to FB/Insta/etc. There were even some media reports that cited Downdetector, seeming without understanding that they are basically crowdsourced and sometimes the crowd is wrong.
I made sure our incident response plan includes checking Hacker News and Twitter for actual updates and information.
As of right now, this thread and one update from a twitter user, https://twitter.com/SiteRelEnby/status/1468253604876333059 are all we have. I went into disaster recovery mode when I saw our traffic dropped to 0 suddenly at 10:30am ET. That was just the SQS/something else preventing our ELB logs from being extracted to DataDog though.
So as of the time you posted this comment, were other services actually down? The way the 500 shows up, and the AWS status page, makes it sound like "only" the main landing page/mgt console is unavailable, not AWS services.
Yes, they are still publishing lies on their status page. In this thread people are reporting issues with many services. I'm seeing periodic S3 PUT failures for the last 1.5 hours.
AWS services are all built against each other so one failing will take down a bunch more which take down more like dominos. Internally there’s a list of >20 “public facing” AWS services impacted.
Meanwhile I moved one of my two internal DNS servers to a second site on 11 Nov 2020, and it's been up since then. One of my monitoring machines has been filling, rotating and deleting logs for 1,712 days with a load average in the c. 40 range for that whole time, just works.
If only there was a way to run stuff with an uptime of 364 days a year without using the cloud /s
> the point is that when it's down, bring it back up is someone else's problem.
When it's down, it's my problem, and I can't do anything about it other than explain why I have no idea the system is broken and can't do anything about it.
"Why is my dohicky down? When will it be back?"
"Because it's raining, no idea"
May be accurate, it's also of no use.
But yes, Opex vs Capex, of course that's why you can lease your servers. It's far easier to spend company money with another $500 a month on AWS than spend $500 a year for a new machine.
My lightswitch is used twice a day, yet it works every time. In the old days it would occasionally break (bulb goes), I would be empowered to fix it myself (change the bulb).
In the cloud you're at the mercy of someone who doesn't even know you exist to fix it, without the protections that say an electric company has with supplying domestic users.
This thread has people unable to turn their lights on[0], it's hilarious how people tie their stuff to dependencies that aren't needed, with a history of constant failure.
If you want to host millions of people, then presumably your infrastructure can cope with the loss of a single AZ (and ideally the loss of Amazon as a whole). The vast majority of people will be far better off without their critical infrastructure going down in the middle of the day in the busiest sales season going.
Many B2B-type applications have a lot of usage during the workday and minimal usage outside of it. No reason to keep all that capacity running 24/7 when you only need most of it for ~8 hours per weekday. The cloud is perfect for that use case.
Scaling itself costs nothing, but saves money because you're not paying for unused capacity.
The main application I run operates in 7 countries globally, but the US is the only one that has enough usage to require additional capacity during the workday. So out of 720 hours in a 30 day month, cloud scaling allows me to pay for additional capacity for only the (roughly) 160 hours that it's actually needed. It's a significant cost saver.
And because the scaling is based on actual metrics, it won't scale up on a holiday when nobody is using the application. More cost savings.
Nice of you to assume that I don't understand the pricing of the services I use. I can assure you that I do, and I can also assure you that there is no such thing as provisioned vs on-demand pricing for Azure App Service until you get into the higher tiers. And even in those higher tiers, it's cheaper for me to use on-demand capacity.
Obviously what I'm saying will not apply to all use cases, but I'm only talking about mine.
Azure, Google Cloud, AWS and others need to have a “Status alliance” where they determine the status of each of their services by a quorum using all cloud providers.
The only uptimes I'm concerned with are my own services that my own monitoring keeps on top of, this varies - if the monitoring page goes down for 10 seconds I'm not worried, if one leg of a smpte-2022-7 is down for a second that's fine, if it keeps going down for a second that's a concern, etc.
If something I'm responsible goes down to the point that my stakeholders are complaining (which is something seriously wrong), they are not going to be happy with "oh the cloud was down, not my fault"
If AWS is down or not it meaningless to me, if my service running on AWS is down or not is the key metric.
If a service is down and I can't get into it, then chatter on things like outages mailing list, or HN, will let me know if it's yet another cloud failure, or if it's something that's affecting my machine only.
>It's because none of these companies are held responsible for missing their actual SLAs, as opposed to their self-reported SLA compliance.
Right, there should be an "alliance" of customers from different large providers (something like a Union but instead of workers, it would be customers). They are the ones that should measure SLAs and hold the provider accountable.
Technically, there are already regulations. SLA lies are fraud.
But I'm leery of any business who's so dishonest they fear any outside oversight that brings repercussions for said dishonesty.
"If not happy, switch" is silly - it's not the customer's problem. And if you're a large customer and have invested heavily in getting staff trained on AWS, you can't just move.
I wonder if there could be profitable play where an organization monitors SLA compliance, and then produces a batch of lawsuits or class action suit on behalf of all of its members when the SLA is violated.
This is a neat idea. Install a simple agent in all customers' environments, select AWS dependencies, then monitor uptime over time. Aggregate across customers, and then go to AWS with this data.
Or just modify sites like DownDetector to show who is hosting each site. When{n} number of sites are down hosted on {x} one could draw a conclusion. It won't be as detailed as "xyz services failed" but rather the overall operational chain is broken. There could be a graph that shows 99% of sites hosted on amazon US East 1 down it would be hard to hide that. This could also paint a picture of what companies are not active-active-multi-cloud.
Cloud providers are not just about web hosting. There are dozens of tools hidden from end users. E.g. services used for background operations / maintenance (e.g. aws codecommit / codebuild / or even aws web console like today). This kind of outages won't bring down your web site, but still might break your normal workflow and even cost you some money.
1,000 comments
[ 4.8 ms ] story [ 385 ms ] threadNothing on their status page. But the Console is not working.
error logging into aws role using saml assertion: error retrieving STS credentials using SAML: ServiceUnavailable: status code: 503
Scratch that... console is not loading at all now :)
Step 1: deploy status checks to an external cloud.
That being said, AWS status pages are up.
0: https://www.redditstatus.com/#system-metrics
I don't think a region being down is something that you can be unsure about.
This is what Amazon, the startup, understood.
Step 1: Always make it right and make the customer happy, even if it hurts in $.
Step 2: If you find you're losing too much money over a particular issue, fix the issue.
Amazon, one of the world's largest companies, seems to have forgotten that the risk of not reporting accurately isn't money, but breaking the feedback chain. Once you start gaming metrics, no leaders know what's really important to work on internally, because no leaders know what the actual issues are. It's late Soviet Union in a nutshell. If everyone is gaming the system at all levels, then eventually the ability to objectively execute decreases, because effort is misallocated due to misunderstanding.
How come an action of a private company in a capitalist country is like the Soviet Union?
Hopefully it results in a class action lawsuit for enough money that Amazon decides that an automated system is better than trying to supply human judgement.
Random aside: any chance you are related to the Calculus on Manifolds Spivak?
He says that any good theorem is worth generalizing, and I've generalized that to any life rule.
looks like only four 9's
It is very unlikely that Amazon would deliberately make your messages cross the Atlantic just to find an American region that is unable to serve you.
"We are experiencing an error. Our apologies – We will be back up soon."
Part of the reason is because their SLAs are based on that dashboard, and that dashboard going red has a financial cost to AWS, so like any financial cost, it needs approval.
Partial availability isn’t the same as no availability.
let me repeat that: my AWS trainign that is run by AWS that I pay AWS for isn't working, because AWS is having control plane (or other) issues. This is several hours after the initial incident. We're doing training in us-west-2, but the identity service and other components run in us-east-1.
edit: partly down; it's sporadically failing
i'd say when other companies who run their infrastruture on AWS are going out, it's hard to argue it's not a real outage.
But AWS status _has_ changed to yellow at this point. Probably heroku could be completely down because of an AWS problem, and AWS status would still not show red. But at least yellow tells us there's a problem, the distinction between yellow and red probably only matters at this point to lawyers arguing about the AWS SLA, the rest of us know yellow means "problems", red will never be seen, and green means "maybe problems anyway".
I believe the entire us-east-1 could be entirely missing, and they'd still only put a yellow not a red on status page. After all, the other regions are all fine, right?
Versus, if a company has X SLA contracts signed, that point to Y reimbursement for being out for Z minutes, so it's easily calculable.
Taken literally what you are saying is the service could be down and an executive could override that, preventing them for paying customers for a service outage, even if the service did have an outage and the customer could prove it (screenshots, metrics from other cloud providers, many different folks see it).
I'm sure there is some subtlety to this, but it does mean that large corps with influence should be talking to AWS to ensure that status information corresponds with actual service outages.
2. Cost is not an issue (until it is but you’re already locked in so oh well)
3. Faang has drained the talent pool of people who know how
If this needed a CEO to eventually get around to pressing a button that said "show users the actual information about a problem" that reflects poorly on amazon.
I think you mean "start thinking they can get what they pay for"
It’s very frustrating. Why even have them?
We can't even update our product to say it's down, because accessing the product requires a process that is currently dead.
> AWS Management Console Home page is currently unavailable.
> You can monitor status on the AWS Service Health Dashboard.
"AWS Service Health Dashboard" is a link to status.aws.amazon.com... which is ALL GREEN. So... thanks for the suggestion?
At this point the AWS service health dashboard is kind of famous for always been green isn't it? It's a joke to it's users. Do the folks who work on the relevant AWS internal team(s) know this, and just not have the resources to do anything about it, or what? If it's a harder problem than you'd think for interesting technical reasons, that'd be interesting to hear about.
Amazing and scary to see all the unrelated services down right now.
My favorite status page, though, is Slack's. You can read an article in the New York Times about how Slack was down for most of a day, and the status page is just like "some percentage of users experienced minor connectivity issues". "Some percentage" is code for "100%" and "minor" is code for "total". Good try.
Mom: Alexa, did you break something?
Alexa: No.
M: Really? What's this? 500 Internal server error
A: ok maybe management console is down
M: Anything else?
A: ...
A: ... ok maybe cloudwatch logs
M: Ah hah. What else?
A: That's it, I swear!
M: 503 ClientError
A: ...well okay secretsmanager might be busted too...
Me: Alexa, is AWS down right now?
Alexa: I'd rather not answer that
That's a bit like involving your kid in an argument between parents.
So what's a good health check actually report these days? Is it just about its own status, or should it include a breakdown of the status of external dependencies as part of its folded up status?
When the biggest cloud provider in the world is famous for gaslighting, it sets expectations for our whole industry.
It's fucking disgraceful that they tolerate such a lack of integrity in their organization.
Some 3600 people have hit that button in the last ~15 minutes.
When Facebook's properties all went down in October, people were saying that AT&T and other cell phone carriers were also down - because they couldn't connect to FB/Insta/etc. There were even some media reports that cited Downdetector, seeming without understanding that they are basically crowdsourced and sometimes the crowd is wrong.
As of right now, this thread and one update from a twitter user, https://twitter.com/SiteRelEnby/status/1468253604876333059 are all we have. I went into disaster recovery mode when I saw our traffic dropped to 0 suddenly at 10:30am ET. That was just the SQS/something else preventing our ELB logs from being extracted to DataDog though.
$ 16:04 up 46 days, 7:02, 9 users, load averages: 3.68 3.56 3.18
US East 1 was down just over a year ago
https://www.theregister.com/2020/11/25/aws_down/
Meanwhile I moved one of my two internal DNS servers to a second site on 11 Nov 2020, and it's been up since then. One of my monitoring machines has been filling, rotating and deleting logs for 1,712 days with a load average in the c. 40 range for that whole time, just works.
If only there was a way to run stuff with an uptime of 364 days a year without using the cloud /s
(Also, OpEx vs CapEx financial shenanigans...)
All the same, I don't disagree with your point.
When it's down, it's my problem, and I can't do anything about it other than explain why I have no idea the system is broken and can't do anything about it.
"Why is my dohicky down? When will it be back?"
"Because it's raining, no idea"
May be accurate, it's also of no use.
But yes, Opex vs Capex, of course that's why you can lease your servers. It's far easier to spend company money with another $500 a month on AWS than spend $500 a year for a new machine.
In the cloud you're at the mercy of someone who doesn't even know you exist to fix it, without the protections that say an electric company has with supplying domestic users.
This thread has people unable to turn their lights on[0], it's hilarious how people tie their stuff to dependencies that aren't needed, with a history of constant failure.
If you want to host millions of people, then presumably your infrastructure can cope with the loss of a single AZ (and ideally the loss of Amazon as a whole). The vast majority of people will be far better off without their critical infrastructure going down in the middle of the day in the busiest sales season going.
[0] https://news.ycombinator.com/item?id=29475499
Most people don't need to scale to a billion users overnight.
And what's a workday anyway, surely you operate globally?
The main application I run operates in 7 countries globally, but the US is the only one that has enough usage to require additional capacity during the workday. So out of 720 hours in a 30 day month, cloud scaling allows me to pay for additional capacity for only the (roughly) 160 hours that it's actually needed. It's a significant cost saver.
And because the scaling is based on actual metrics, it won't scale up on a holiday when nobody is using the application. More cost savings.
Obviously what I'm saying will not apply to all use cases, but I'm only talking about mine.
https://www.thomas-krenn.com/en/wiki/Processor_P-states_and_...
Which is an implementation of:
https://web.eecs.umich.edu/~twenisch/papers/asplos09.pdf
Status pages are virtually useless these days
Every major company has moved away from having accurate status pages.
So unless regulation gets implemented that says otherwise, there's zero incentive for any company to maintain an accurate status page.
If something I'm responsible goes down to the point that my stakeholders are complaining (which is something seriously wrong), they are not going to be happy with "oh the cloud was down, not my fault"
If AWS is down or not it meaningless to me, if my service running on AWS is down or not is the key metric.
If a service is down and I can't get into it, then chatter on things like outages mailing list, or HN, will let me know if it's yet another cloud failure, or if it's something that's affecting my machine only.
Right, there should be an "alliance" of customers from different large providers (something like a Union but instead of workers, it would be customers). They are the ones that should measure SLAs and hold the provider accountable.
If not happy with the results switch.
But I'm leery of any business who's so dishonest they fear any outside oversight that brings repercussions for said dishonesty.
"If not happy, switch" is silly - it's not the customer's problem. And if you're a large customer and have invested heavily in getting staff trained on AWS, you can't just move.
Really not that complicated.