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

31–40 of 137 posts

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

#31

Post by naikrovek »

donavanm wrote: post #19

I'm a principal at AWS and spent years dealing with this on CloudFront and Route 53. A lot right, and a little off, in the post. Yes, we should definitely communicate to the viewer what's happened and appropriate next steps if any. But there are a handful of challenges that Ive not seen reasonably solved. The first problem is that different viewers need different context, which is especially true for service provider…

these seem solvable.

there's no reason that a good error message AND pertinent support information are mutually exclusive. show them both.

show the errors that make sense for that action and that error. no one is saying that there should be a small list of "approved" errors that everyone would see. show what makes sense in that situation, and don't show something that doesn't help.

you don't need to have prophetic insight into the actual causes. just show the flipping errors. don't hide things behind friendly messages; show the friendly message and the error. it's insulting when an error message is hidden from me in favor of something like "oopsies! we broke something! so sorry!!" insulting and disrespectful.

there is no need for a single solution. do what's right for you, and most of all, start thinking about ways that things can work, instead of going straight to the reasons that they might not. don't talk yourself out of a good decision because it might not work for every last situation.

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

#32

Post by rozenmd »

donavanm wrote: post #19

I'm a principal at AWS and spent years dealing with this on CloudFront and Route 53. A lot right, and a little off, in the post. Yes, we should definitely communicate to the viewer what's happened and appropriate next steps if any. But there are a handful of challenges that Ive not seen reasonably solved. The first problem is that different viewers need different context, which is especially true for service provider…

Hey,

Fair point, I mainly picked the first contrived example that came into mind, rather than thinking long and hard about what the "correct" error message should be.

Will update the article to clarify that.

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

#33

Post by QuinnyPig »

donavanm wrote: post #19

I'm a principal at AWS and spent years dealing with this on CloudFront and Route 53. A lot right, and a little off, in the post. Yes, we should definitely communicate to the viewer what's happened and appropriate next steps if any. But there are a handful of challenges that Ive not seen reasonably solved. The first problem is that different viewers need different context, which is especially true for service provider…

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.

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

#34

Post by herpderperator »

cbsks wrote: post #28
gonzo41 wrote: post #5

So that looks like a stock Varnish 503. I'm pretty sure the magic behind fastly is a ton of Varnish cache. What's interesting (VCL can be unforgiving), also that it was a big central stuff up. Which makes me think they have layers and layers of caching in depth and some top level config just blacked out everything. I kind of would have thought they'd have lots of small instances.

> So that looks like a stock Varnish 503 Looks like it, except that Varnish has it spelled “Guru Meditation”, not “Guru Mediation”. Anyone know why that would be? https://github.com/varnishcache/varnish-cache/search?q=medit...

Try searching an older branch manually. GitHub only searches the main branch.

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

#35

Post by judge2020 »

naikrovek wrote: post #31
donavanm wrote: post #19

I'm a principal at AWS and spent years dealing with this on CloudFront and Route 53. A lot right, and a little off, in the post. Yes, we should definitely communicate to the viewer what's happened and appropriate next steps if any. But there are a handful of challenges that Ive not seen reasonably solved. The first problem is that different viewers need different context, which is especially true for service provider…

these seem solvable. there's no reason that a good error message AND pertinent support information are mutually exclusive. show them both. show the errors that make sense for that action and that error. no one is saying that there should be a small list of "approved" errors that everyone would see. show what makes sense in that situation, and don't show something that doesn't help. you don't need to have prophetic in…

Showing the error itself only opens the provider to information disclosure - with the various automated infrastructure monitoring systems running on Fastly or CF they know when and where errors are happening with full traces that help them debug.

> there's no reason that a good error message AND pertinent support information are mutually exclusive. show them both

As the OP stated, there is quite literally nothing support can do for system-wide outages like this, and when you show support information on these pages, the regular users that see them end up asking for support. There are a non-zero amount of posts monthly on the Cloudflare community forum from people asking about error messages they see for sites they don’t own.

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

#36

Post by foxpurple »

andyfleming wrote: post #21
aniforprez wrote: post #10

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

One of the reasonable reasons why errors often get returned generically is because of security though.

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.

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

#37

Post by donavanm »

rozenmd wrote: post #32
donavanm wrote: post #19

I'm a principal at AWS and spent years dealing with this on CloudFront and Route 53. A lot right, and a little off, in the post. Yes, we should definitely communicate to the viewer what's happened and appropriate next steps if any. But there are a handful of challenges that Ive not seen reasonably solved. The first problem is that different viewers need different context, which is especially true for service provider…

Hey, Fair point, I mainly picked the first contrived example that came into mind, rather than thinking long and hard about what the "correct" error message should be. Will update the article to clarify that.

Cheers. Didnt mean to be too contrarian here or pick apart the broader message, which I absolutely agree with. More of an expression of my personal experience struggling with the same problem. As unsatisfying as it is I suspect you settle for getting it right 95% of the time and including enough details that the user can self service, or contact support, in the other cases.

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

#38

Post by foxpurple »

sachinag wrote: post #18
xwdv wrote: post #4

Good error messages are hard. There’s so many things that can go wrong, and each needs its own custom explanation. Never really found a good way to organize this. And since errors should be uncommon, it feels like a waste of time coming up with thoughtful messages.

Good error messages have a template: a UUID, a description, and a suggested solution. This gives folks enough to try to solve it themselves and also enough to Google / grep with.

You can’t suggest a solution because if you were aware of the problem enough to suggest a solution you would just fix the problem. This 503 error from fastly was never meant to show to a user. You can’t do much to account for novel situations which shouldn’t ever happen.

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

#39

Post by donavanm »

cbsks wrote: post #28
gonzo41 wrote: post #5

So that looks like a stock Varnish 503. I'm pretty sure the magic behind fastly is a ton of Varnish cache. What's interesting (VCL can be unforgiving), also that it was a big central stuff up. Which makes me think they have layers and layers of caching in depth and some top level config just blacked out everything. I kind of would have thought they'd have lots of small instances.

> So that looks like a stock Varnish 503 Looks like it, except that Varnish has it spelled “Guru Meditation”, not “Guru Mediation”. Anyone know why that would be? https://github.com/varnishcache/varnish-cache/search?q=medit...

You've found a kind "trap street". This disambiguates the error message generated from Fastly vs the error message generated from an origin which happens to use varnish as well.

Edit: As to why Fastly wants to expose the relatively stock error message instead of custom text, I dont know. My guess would be Faslty (or their customers) have tooling built around parsing the http response and they're preserving compatibility.

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

#40

Post by adreamingsoul »

donavanm wrote: post #19

I'm a principal at AWS and spent years dealing with this on CloudFront and Route 53. A lot right, and a little off, in the post. Yes, we should definitely communicate to the viewer what's happened and appropriate next steps if any. But there are a handful of challenges that Ive not seen reasonably solved. The first problem is that different viewers need different context, which is especially true for service provider…

Agreed.
Post reply on HN