What the Fastly outage can teach us about writing error messages
1–10 of 137 posts
Re: What the Fastly outage can teach us about writing error messages
#2Have they published a post-mortem for the outage yet? I'm curious as to what happened here
Re: What the Fastly outage can teach us about writing error messages
#3I've had more than one intern or young engineer that I've had to teach to resist the urge to put witty comments and jokes in project docs, comments, or errors. Especially in error messages or things that can be exposed to users/customers. Even if it's an error you think only the dev team will see, you never know if it will make its way out to audiences you didn't intend. Somehow I doubt people faced with this error message really were amused by the reference to the old Amiga OS errors....
Re: What the Fastly outage can teach us about writing error messages
#4Good 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.
Re: What the Fastly outage can teach us about writing error messages
#5So 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.
Re: What the Fastly outage can teach us about writing error messages
#6Good 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.
The problem is that you have to know exactly what has gone wrong to show a proper message. But if you know what is wrong, most of the time the correct action is to fix the program so it does not go wrong instead of showing a better error.
With the main exception of user submitted data validations where it is up to the user to submit correct data. For the average web service, there the error is a stack trace and there is nothing the user can do so a blank screen with a "something went wrong, we have logged this erorr" is the only real option.
Re: What the Fastly outage can teach us about writing error messages
#7But who's going to host that nice unicorn images? and those nice CSS? I agree with putting up a link tho.
Re: What the Fastly outage can teach us about writing error messages
#8But who's going to host that nice unicorn images? and those nice CSS? I agree with putting up a link tho.
Embed both in the page.
Re: What the Fastly outage can teach us about writing error messages
#9I've had more than one intern or young engineer that I've had to teach to resist the urge to put witty comments and jokes in project docs, comments, or errors. Especially in error messages or things that can be exposed to users/customers. Even if it's an error you think only the dev team will see, you never know if it will make its way out to audiences you didn't intend. Somehow I doubt people faced with this error m…
> Somehow I doubt people faced with this error message really were amused by the reference to the old Amiga OS errors....
I'll bet whoever put that in there feels extra silly about misspelling "meditation", too.
Re: What the Fastly outage can teach us about writing error messages
#10Reminds me of the quintessential tweet about error messages
https://twitter.com/cherrikissu/status/972524442600558594?s=...