Live data from Hacker News

Summary of the Amazon DynamoDB Service Disruption

aws.amazon.com

51–60 of 89 posts

Re: Summary of the Amazon DynamoDB Service Disruption

#51

Does anyone keep stats on service outages for AWS, Axure, Google, et al?

I currently track a lot of this through my project StatusGator which alerts you on outages: https://statusgator.io . Most of the historical data isn't shown publicly but I could probably do something with that.

The historical data would be quite useful for companies when deciding which cloud providers to contract with.

Re: Summary of the Amazon DynamoDB Service Disruption

#52
post #41

As this post is on, Dynamo is experiencing error again: 6:33 AM PDT We are investigating increased error rates for API requests in the US-EAST-1 Region. Source: http://status.aws.amazon.com/

Thank you for this. I was wondering why I was getting slow responses from their API Gateway. It's "green" on their status board, but based on what I saw Sunday, the two services are linked.

Re: Summary of the Amazon DynamoDB Service Disruption

#53
post #41

As this post is on, Dynamo is experiencing error again: 6:33 AM PDT We are investigating increased error rates for API requests in the US-EAST-1 Region. Source: http://status.aws.amazon.com/

Thank you for this. I was wondering why I was getting slow responses from their API Gateway. It's "green" on their status board, but based on what I saw Sunday, the two services are linked.

Pretty much the exact same thing that happened the other day. DynamoDB, then Lambda, now API Gateway. I can't update my Lambda functions, a small percentage are timing out, and API Gateway is sending back a "We're out of capacity" message.

Re: Summary of the Amazon DynamoDB Service Disruption

#55

Earlier quoted context omitted.

What's with this all-or-nothing attitude? What is so wrong about different severity levels? Green-i: Some small percentage of customers are affected, but most of you have nothing to worry about. So if you are a customer having problems and see this notice, you are re-assured that you are not crazy. And if you are NOT seeing problems, you probably won't. Amazon has not always been the best at posting this information…

different severity levels are fine. That's what the indicator is for. Decorating the indicator, normally completely incorrectly, with a tiny extra indicator, is incomprehensible. That's why you've never seen a tiny red light in the upper corner of your green traffic light. Your 'check engine' light is not green with a tiny extra indicator in the corner. The metaphors go on and on. Customers are totally not interested…

The question of timing of the green-I is valid, but different from your original complaint.

In your hypothetical scenario, the customer that is going to the panel to "find out what the fuck is going on" is not going to miss the indicator i, and will read the description of the message.

Re: Summary of the Amazon DynamoDB Service Disruption

#56
post #41

As this post is on, Dynamo is experiencing error again: 6:33 AM PDT We are investigating increased error rates for API requests in the US-EAST-1 Region. Source: http://status.aws.amazon.com/

Their status screen is totally misleading and utterly pointless. Someone needs to get all of the RSS feeds (which are actually accurate) and create a new dash which is honest.

Re: Summary of the Amazon DynamoDB Service Disruption

#58
post #57

[deleted]

I very much doubt that's an actual confession. The rest of their LinkedIn profile (https://www.linkedin.com/in/danveloper) is a series of way-too-honest "I fucked up and got fired" jobs.

> Although I signed up for a programming job, I was tasked with literally seeding clouds. I actually had to fly an airplane and dispel a solution of silver iodide into the air to -- quite literally -- "make it rain". I would've stayed here forever if the company hadn't gone under. Unfortunately, as it turned out, hiring programmers to manipulate the weather turned out to be a bad management policy. Oh well... ce la vie.

Re: Summary of the Amazon DynamoDB Service Disruption

#59
post #32

I noticed that in the "Impact on other services" bit, that CloudWatch and Console were affected, becasue they were dependent on DyanmoDB. Now, I don't pretend to know DyanmoDB to well, but it seems to me that having your monitoring application dependent on one of the things you would be monitoring is a strange circular dependency. Would it have been wiser for Amazon to implement a completely separate instance of Dyna…

CloudWatch is a monitoring service that AWS offers publicly. It is different from the monitoring service that AWS services use internally. source: was on an AWS service team for several years

It's still a problem even if it's not the internal monitoring system. Customers use CloudWatch to detect problems with DynamoDB and get notified. This dependency means customers may not get notified if CloudWatch does not work as expected due to a DynamoDB problem.

Re: Summary of the Amazon DynamoDB Service Disruption

#60

Earlier quoted context omitted.

different severity levels are fine. That's what the indicator is for. Decorating the indicator, normally completely incorrectly, with a tiny extra indicator, is incomprehensible. That's why you've never seen a tiny red light in the upper corner of your green traffic light. Your 'check engine' light is not green with a tiny extra indicator in the corner. The metaphors go on and on. Customers are totally not interested…

The question of timing of the green-I is valid, but different from your original complaint. In your hypothetical scenario, the customer that is going to the panel to "find out what the fuck is going on" is not going to miss the indicator i, and will read the description of the message.

It's really easy to miss the indicator "i". I've been doing this for 4 years and it still doesn't catch my eye when scanning the page.
Post reply on HN