Better Ways to Use 404 & 500 Error Pages

September 30, 2015 Comments


In this article, we cover something that is a huge “bang for the buck” when it comes to communicating with customers: Error pages.

Impact Index

Initial Effort LowHigh
Ongoing Effort LowHigh

This best practice ranks Low to Medium on Initial Effort: It’ll take a bit of developer time, but it’s fairly straightforward.

This best practice ranks Low on Ongoing Effort: Once you get it going, there won’t be a lot for you to do, but what data you get from it will be incredibly valuable.


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.

In addition to 500, there are dozens of other error codes such as 400, 401, 402, 403, 502, 503, and 504. Each of them means something very specific, but many web apps lump them together under a single, static error page. For the sake of brevity, we’ll refer to all errors as 500s for the rest of this article.

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:

nginx 502 error page
nginx: Who’s a bad gateway?! You’re a bad gateway!

 

Ruby on Rails rocked the error page world when it launched this radically advanced error page back in 2006:

Ruby on Rails default error page
Rails: Much style. Many color.

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:

CSS-Tricks.com error page
Title tag: “You’ve ripped a hole in the fabric of the internet. Love, Chris from CSS-Tricks”

 

Even companies like The North Face got into the game:

The North Face error page
Goats: Don’t let them win.

 

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:tnfsupport@vfc.com. 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 /billing. #facepalm

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.

Early on in Ramen’s history, anytime someone hit an exception, I would personally email them saying that I saw the error and a fix was coming. For every exception. This was never an overwhelming amount, and I believe it was one of the keys to getting our business off the ground.

ramen-404-toolbox1

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:

  1. Clicked a link or button while using the app
  2. Clicked a bookmark — Great for identifying changed routes in your product
  3. Followed a link shared by someone — Can quickly give you a hint as to whether this is actually your fault
  4. 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?

We haven’t mentioned Single Page Apps (SPA), but they deserve some attention here. SPAs are apps written with lots of front-end JavaScript. If you’re not technical, but you’ve heard your tech dudes and dudettes refer to Ember, React, Meteor, AngularJS, etc…. then your product is probably an SPA. Once the first page loads in an SPA, the page doesn’t refresh. The URL might not change at all as you move around the app. If the URL does change, related changes to the state of the application are almost instant.

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:

  1. 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.
  2. Exceptions in SaaS products are much rarer per pageview than for content/e-commerce, which further decreases the chances of them being shared & found.
  3. 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

 

Thank You

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:

Get Started with Ramen for FREE

What Do You Think?

Nothing to see here. Just a yeti.

© Ramen Inc. 2017