Due to HN's flaky Cloudflare 503 Bad Gateway error, I noticed that Cloudflare is also being affected by S3 being down in a similar but subtle way. See their status page's broken logo on the upper left hand corner.[1] It was actually directly linking to a S3 URL: https://s3.amazonaws.com/statuspage-production/pages-transac...

[1]: https://www.cloudflarestatus.com/

https://www.cloudflarestatus.com/ http://www.trellostatus.com/

Looks like they are both using the same solution for their status pages. The icon for trellostatus did also fail to display.

Was HN affected by Cloudbleed?

I would rather access HN without Cloudflare as man-in-the-middle, especially over HTTPS.

All websites that use Cloudflare were potentially affected by Cloudbleed which is what makes it such a terrible thing.

You will never know the exact damage, the only thing you can do to play it 100% safe is to rotate all credentials on sites using Cloudflare.

And you can't access HN without going through Cloudflare (unfortunately, but HN is having a hard enough time to keep up with traffic as it is, without Cloudflare it would perform a lot worse than it does).

Hahaha too bad.

Google Analytics, Cloudflare, AWS, those are things you can never escape from.

Disagree on Google Analytics.

EDIT: Misread parent.

Because your status page shouldn't depend on your own infrastructure. Literally the problem Amazon is having right now.

I guess they don't want to host their status page on their own CDN in case it went down too.

But only the logo image hosted on S3 is broken though. It seems to be preventable if they host the logo image together with their status page.

Saw that too, sounds like a convenient excuse for being caught in a lie.

AWS Employee #1: Hey, people are catching on that our status page isn't accurate

AWS Employee #2: Tell them it's cause of S3

I'd suspect the humiliation of hosting your own status page on the infrastructure it's monitoring would far outweigh the "lie".

People are much more forgiving of mistakes than they are of deception.

The icons aren't hosted there (or if they are, they are cached). https://status.aws.amazon.com/images/status3.gif

The status information is hosted there.

Looks like the dashboard is fixed https://twitter.com/awscloud/status/836662601090134017

The "red check mark is stored on S3" may have been sarcasm, but apparently there was a kernel of truth to it?!

Poor show when a service disruption means the status page can't be updated....

While status icon being hosted on S3 is funny, I think it's more likely that it's not the icon itself that caused the status page to not getting updated, but rather the fault of service information (say, a JSON file) that used to generate the status page that was stored on S3. The banner could probably be configured locally, so they choose to update that for the time being (e.g. while moving the status bucket somewhere else).

> Update at 11:35 AM PST: We have now repaired the ability to update the service health dashboard.

I like how HN (and others) handle this - there should be a static link to a 3rd party source, like a twitter feed, at the top of any status page.

if that simple, why the text desc for Details also didn't reflect the incident?

Is there any service that distributes your files to multiple cloud services at the same time? With this recent S3 outage, I'm now feeling uneasy to store files on S3 for mission critical apps.

The outage was on us-east-1. If you are hosting mission-critical files in a single region, S3 is not the problem.

To be fair, most people don't use the region replication thing for S3. Of course this is why I push folks to use GCS's default Multi-Regional buckets, because when a regional outage does occur, it's awfully nice to at least have the option to spin up elsewhere. If your critical data is in Virginia today, all you can do is wait.

Disclosure: I work on Google Cloud, and we've had our fair share of outages.

ins3ption