Sometimes 404s hide big errors. If you don’t track them you may be screwed.

Hoptoad doesn’t seem to track 404s, so even if you use that nobody is going to knock you over the head. It’s going to fail silently for tons of people until your customers call you to complain.

How it begins

Most of you know this, but here’s why:

Say you have a resource that you’re using in a few obscure places in your code:

1
2
3
4
5

# config/routes.rb

map.resources :petitions

1
2
3
4
5

# app/views/obscure/deeper/random.html.erb

<%= link_to new_petition_path %>

Say you currently have an action in the PetitionsController that obviously handles the request for petitions/new.

How the error happens

8 months from now, though, you realize that your business has changed such that there is no longer a need for a petitions/new action. You delete the new method on the PetitionsController.

Now, unless you have either 100% test coverage or you think to do a project search, you will get a silent 404.

This is because the file in app/views/obscure/deeper/random.html.erb still uses the path for the new petition action. Since the new_petition_path method doesn’t give a no method error b/c it’s setup in routes.rb, you won’t get a 500 for Hoptoad. Instead, since undefined actions on controllers return 404s, you’ll get a silent error.

To avoid this, use google analytics, or preferably something more immediate to handle 404 tracking.

Update

Trevor notes that:

“I think you can tell hoptoad to track 404s so you can see them on the site, but they still won’t email you:

1
2
3
4
5
6
7
8

HoptoadNotifier.configure do |config|
 config.api_key = 'sdfsddf'
 config.ignore_only  = [ActiveRecord::RecordNotFound, ActionController::InvalidAuthenticityToken]
end

“