In this article, we cover something that is a huge “bang for the buck” when it comes to communicating with customers: Error pages.
When something goes wrong with a web app, it’s common to display an error page. There are dozens of different types of errors, but the most common are 404: Not Found and 500: Server Error.
Your end users get a 404 when they go to a non-existent URL, such as https://ramen.is/a-url-which-will-never-exist-or-will-it. This can happen due to typos or things being deleted/moved. They get a 500 when there has been some sort of error in your application.
Since error pages mean–surprise!–there’s been an error, they are usually very simple, static pages. You wouldn’t want to put any dynamic code in your error page that could throw an error, which would then want to load the error page, which has code, which throws an error Because of this, we’re all familiar with the standard error pages from the likes of nginx:
Ruby on Rails rocked the error page world when it launched this radically advanced error page back in 2006:
We should spend way more time on our error pages… making them funny!
The next big evolution in error pages came when people realized they could make them funny. We have Chris Coyer at CSS-Tricks doing stuff like this:
Even companies like The North Face got into the game:
Is this an error or a 404 page? Not super clear. Report to the Web Administrator doesn’t really scream “We care about your experience and want to fix whatever it is that got you here.” This sentiment is reinforced when you click it and find that it’s just a mailto:firstname.lastname@example.org. This is a great example about how putting effort into a 404 page can actually be a net negative.Error pages should clearly state that something is missing or broken. To do otherwise, even for the noble goal of Goat Shenanigan Awareness, risks confusing your customers.
SaaS != Everything else
For many types of businesses–i.e. content or e-Commerce sites–what we saw above isn’t ideal, but it’s not a huge tragedy either. Visitors pretty much expect to get these error pages. Who hasn’t clicked on a link in a tweet or email that had a typo? Happens all the time.
But for SaaS products, these pages are a big deal. Your customers might have been mid-workflow. This might have been the one time a month they click on that button to get whatever it is they pay you $5,000/month for. They click “Send” and get an error page. Not cool. If you’ve spent any time making a funny 500 page, at that moment your customer might not share your sense of humor.
Error pages should be better
I’d like to think that by this point you’re already onboard with how important it is to ensure your error pages don’t just say “LOL ERROR”, but I’m going to belabor the point.
Not only does an error page mean your customer was unsuccessful at finding or doing something, but sometimes you don’t even know it’s happening.
Product Fail Yeti says:
If you’re not using an exception monitoring service like Rollbar or Airbrake, AWESOME. Don’t ever use them. Who cares that these services have extremely generous free tiers, and are dirt cheap after that? Be just like me. Let your users hit those errors without having any idea about it!
Can you believe that guy? Don't listen to the Yeti. #FightTheYeti
Even if you have exception monitoring in place, most of them don’t record 404s. I once learned this the hard way, because it turns out that it’s a super big deal when your billing page is at
/manage/billing but your navigation links to
All that being said, it’s still possible that you will miss errors. There are multiple layers of software between the Internet and your web application (eg. nginx, varnish, unicorn), and it’s possible for any layer to throw various types of errors even when there hasn’t been an “error” as far as your application is concerned.
How error pages can be better
Error pages are usually static for good, technical reasons, but that doesn’t mean there isn’t room for improvement.Your error pages should ask your customers how they got there and what they were expecting. Your error pages should apologize for the inconvenience. If it’s the truth, your error pages should tell your customers that you’ve been notified, give a crap, are looking into it, and will follow-up with them.
Error Page Toolbox
Asking questions on your error pages is something you can design and build yourself. Our best practice is to ask: “How did you get to this page?” and supply a series of options:
- Clicked a link or button while using the app
- Clicked a bookmark — Great for identifying changed routes in your product
- Followed a link shared by someone — Can quickly give you a hint as to whether this is actually your fault
- Other — Always give them an out
In addition to asking questions, a custom solution also gives you the flexibility to store additional details like exception data and session information to aid in debugging.
One thing to keep in mind, though, is that to work correctly, this system must be isolated from your main application in the event of a cataclysmic failure. That means using a different application, database, and should probably even be hosted on a separate server. That’s a lot of work, and I told you earlier this was Low to Medium on the Initial Effort scale, so below, I list three 3rd-party services you can use on your error pages. Each of them have generous free usage tiers, and can be setup in ~5 minutes.
Method 1: Google Forms
Google Forms is free forever, and provides a simple way to add a questionnaire form directly to your 500 pages. I was able to create a new form and add it to Ramen’s error page in about 4 minutes and 30 seconds. Not kidding. Here’s the video sped up 4x
Method 2: Wufoo
Another option is Wufoo, which has a generous free tier and integrates with many other services. It took me under 5 minutes and 30 seconds to create an account and have a form live on Ramen’s error page. Here’s that video sped up 4x:
Method 3: Ramen
Not all articles in this series will promote Ramen, but for this best practice, Ramen is an option. We have pre-canned 40x & 50x questions that you can use, and some extra goodies that help managing responses at scale a breeze:
What about single page apps?
SPAs are built differently than ‘standard’ web apps, but everything we talked about above still applies. However, since most SPA errors are asynchronous, there’s not really any error page to show.
Normally, SPAs are built to catch errors on their asynchronous requests and display error messages accordingly, but errors still slip through the cracks. And if anything, it’s those errors that will be most confusing & frustrating for your customers. In this case, it’s still possible to use the above products to ask your customers questions when they encounter errors. You just need to do a little extra coding. In the case of jQuery w/ Ramen, for example, all it takes is the following snippet to pop-up a question on an AJAX error:
In the wild
We looked around for companies that do this well to include as case studies, but we had a tough time finding any. We believe this is for 3 reasons:
- Fewer people use SaaS products than visit content/e-commerce sites, so they’re less likely to pop up in “Best Error Page Posts” that abound if you go Googlin’ for them.
- Exceptions in SaaS products are much rarer per pageview than for content/e-commerce, which further decreases the chances of them being shared & found.
- And, sadly, because so few people are doing it.
If you have built or used a SaaS product that has great error pages, please leave them in the comments, and we’ll add them to this post.
Until next time!Wrong form ID
None of these articles would be possible without a lot of time given by a lot of people that don’t work for Ramen. Thanks for this article goes out to: