Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What the Fastly outage can teach us about writing error messages

onlineornot.com

Post reply on HN
Print view View original

131–137 of 137 posts

Re: What the Fastly outage can teach us about writing error messages

#131

Post by foxpurple »

bandie91 wrote: post #104
foxpurple wrote: post #36

Earlier quoted context omitted.

Exactly usually the real error message behind the “oopsie” is a stack trace containing sensitive information and environment variables. It is no use to the user since they can’t do anything and is actually dangerous to give out.

aws exceptionally performs well in this question: in some IAM-related (permission management) API error messages contains encrypted details so it does not leak sensitive data but the support can decrypt an analyze it if the user pastes it back.

An alternative is just showing the request ID so support can look up the error in logging

Re: What the Fastly outage can teach us about writing error messages

#132

Post by QuinnyPig »

Xorlev wrote: post #123
QuinnyPig wrote: post #33

Earlier quoted context omitted.

Very true, at the individual error level. That said, Fastly fixed the entire issue in less time than it would have taken AWS to update the status page to the blue diamond, so there’s that.

In large organizations, status boards are "external communications" and this must be handled by a team dedicated to that. It works about as well as you might expect.

Fastly isn’t exactly small, and their status page was updated continuously throughout the incident.

Re: What the Fastly outage can teach us about writing error messages

#133

Post by [deleted] »

marcosdumay wrote: post #128
rantanplan wrote: post #121

Earlier quoted context omitted.

> Are you aware that those things go through a design phase with the explicit objective of giving them a personality, right? Not really. I see quite the opposite; during the design phase the team sets the rules in order to guarantee consistency and cohesiveness and avoid any deviation from what has been agreed upon. This rules out personal or whimsical contributions, because by definition it would ruin the process. >…

Teams? Rules? The bridge architects you are talking about behave very differently from the ones I've met.

[deleted]

Re: What the Fastly outage can teach us about writing error messages

#134

Post by rantanplan »

marcosdumay wrote: post #128
rantanplan wrote: post #121

Earlier quoted context omitted.

> Are you aware that those things go through a design phase with the explicit objective of giving them a personality, right? Not really. I see quite the opposite; during the design phase the team sets the rules in order to guarantee consistency and cohesiveness and avoid any deviation from what has been agreed upon. This rules out personal or whimsical contributions, because by definition it would ruin the process. >…

Teams? Rules? The bridge architects you are talking about behave very differently from the ones I've met.

I haven't met that many bridge architects :D

But do they build bridges by themselves? Are bridges built by a one man show?

And they don't have rules? And how do they get anything done?

Re: What the Fastly outage can teach us about writing error messages

#135

Post by marcosdumay »

rantanplan wrote: post #134
marcosdumay wrote: post #128

Earlier quoted context omitted.

Teams? Rules? The bridge architects you are talking about behave very differently from the ones I've met.

I haven't met that many bridge architects :D But do they build bridges by themselves? Are bridges built by a one man show? And they don't have rules? And how do they get anything done?

Are you sure you did read my previous comment? You are replying to stuff that isn't there.

About rules, no, nobody pass rules down the stream. People communicate full designs of some issue (that is not the full design of the thing, designs are "sectorial" where people add their concerns into the overall thing). When it's done right, the design goes to and from those sectors changing the entire time. When it's done badly, somebody finishes a "general" design and sends it downstream for people to fill the other parts. A team does not work on the same issue, that would be chaos.

Re: What the Fastly outage can teach us about writing error messages

#136

Post by Xorlev »

QuinnyPig wrote: post #132
Xorlev wrote: post #123

Earlier quoted context omitted.

In large organizations, status boards are "external communications" and this must be handled by a team dedicated to that. It works about as well as you might expect.

Fastly isn’t exactly small, and their status page was updated continuously throughout the incident.

This was in response to the AWS status page.

Re: What the Fastly outage can teach us about writing error messages

#137

Post by nephanth »

calvinmorrison wrote: post #20
aniforprez wrote: post #10

Reminds me of the quintessential tweet about error messages https://twitter.com/cherrikissu/status/972524442600558594?s=...

Right up there with Slack etcs fake loading messages "Gearing up the dildonator" "Implicating the fairies" "Hogtying George Bush" Dude - just give me a spinner or a progress bar, and if something errors during the load out give me some sort of stack trace or error ID I can use to help

Well discord has fake loading messages too, and I think they're funny. Though it's a bit different since discord is not aimed at professionnals, the geeky jokes match better with the gamer audience
Post reply on HN