Error page details
Sometimes you’ll have recurring exceptions that are just noise. They don’t mean that your app is broken. In these cases you may want to have Honeybadger ignore the exception.
When you ignore an exception:
- We won’t log any re-occurrences
- You won’t see the error in your default error list
Flagging an exception as “ignored”
To mark an exception as ignored, just click on the Ignore button in the errors details page, and choose the last option in the list. If you want to pause notifications for a while without completely ignoring the error, choose from one of the other options. Once you have chosen one of these options, the Ignore button will change to Un-Ignore. Clicking that button will cause errors notifications to be recorded again if you chose the last option, or will cause notifications to be resumed if you chose one of the other options.
RAM and CPU Load
Whenever an exception occurs, we take a snapshot of system RAM usage and load. You’ll see the following stats:
- RAM in use: The amount of memory in use
- Ram free: The amount of memory not used at all
- Ram Available: The amount of memory that the OS is using, but which can be freed for use by other apps.
- Load Average: The 1, 5 and 15 minute load averages - What is load?
If you forget this, just mouseover the little pie charts for a helpful tooltip.
Note: System snapshots are only currently supported on linux. They won’t work on OS X or Windows.
The meaning of the load average depends on the # of cores in your server. The more cores you have, the higher the load average will normally be.
It’s simplest just to look at some examples.
For a 1-core server
- A load of 1 means the CPU is working at 100% capacity.
- A load of 0.5 means it’s at 50% capacity.
- A load of 1.5 means it’s overloaded…you’re trying to use 150% of CPU.
For a 3-core server
- A load of 3 means the CPU is working at 100% capacity
- A load of 1.5 means the CPU is working at 50% capacity
- A load of 6 means it’s working at 200% capacity and is overloaded.
To learn more, check out the wikipedia entry.
Error history log
Each exception has an audit trail. It’s actually part of the Comments section. If you go to any error details page and scroll down to the comments, you’ll see that the comments are placed in a timeline with other events related to the error.
The audit trail will show you
- When an error was first reported
- When it was resolved or unresolved
- If it was resolved manually, or automatically on deploy
- When it was assigned to a person, or unassigned
Individual Error Occurrances
With Honeybadger you can go back in time to see previous occurrences of an exception that just occurred. This not only gives you context so you can see what inputs caused an error, but it also lets you see who was affected by an error.
To view older or newer versions of an exception, use the arrow buttons in the subnavigation. You can also use the left and right keys on your keyboard.
Params, Cookies & Session
When an error happens in your app, we suck in as much debug info as possible and present it to you in the error details page.
Types of debug data
- Error summary: With any luck, this is all you’ll need to fix the problem
- Context data: This is custom data that you can send along with your errors. See how.
- Params: Similar to rails’ params hash, these are the HTTP request parameters for the request that caused an error. For rake tasks and other non-web uses, you can set these to whatever you like.
- Session: The user’s rails session hash
- Cookies: The user’s cookies at the time of the error
- Environment: Server and web environment variables.
- Trace: The backtrace for the exception
- Comments: Your team’s discussion surrounding the erorr
- Deploys: See which deployments affected error status
All of this data is displayed on a single page. You can quickly jump to the different sections using the orange navigation bar.
Using the data
All data structures are presented as valid ruby code. So you can easily copy and paste. Each section has a copy-to-clipboard link at the bottom left corner (mouse-over the section to show it).
Resolved / Unresolved
Marking an error resolved or unresolved in honeybadger is a lot like opening and closing tickets in an issue tracker.
Not only is error resolution a useful way to keep track of which bugs are the most pressing, it also plays a critical role in how we notify you.
If we see a new exception, we notify you. But if we see an old exception that’s been marked resolved, we also notify you. Since you’ve marked it resolved, we assume that a reoccurrence is something you’d be interested in.
From the exception list
From the error details page
Honeybadger knows how to handle exceptions from different environments. If an error occurs on staging, and then happens again on production, we treat those as two separate errors.
Many people have staging servers, or other apps that use non-standard environments. That’s not a problem. Just start sending us errors from those environments and we’ll start recording them.
Our comments support Markdown! If you’re not already familiar with it, you can read about the basics here.
Here’s an example:
The comment will be rendered like this:
We also support GitHub flavored Markdown. You can add syntax highlighting like this:
The comment will be rendered like this:
Assign to user
Want to tell one of your collaborators that they need to fix a certain bug? Assign the exception to them. Want to let your team know that you can handle it? Assign it to yourself.
When you assign an issue:
- The assignee is notified
- The issue is added to their list. Anyone on your team can see who owns which issues.
- An entry is made in the audit log, so you know who to turn to when the problem reoccurs 2 years later
To assign an issue, just:
- Go to the error details page
- Select a user from the dropdown. That’s it! It auto-saves.
We interpret the user-agent of all web requests and show you either a browser logo, or a picture of a cute robot if the request came from a bot.
Usually, when there’s a bug in your code it’s in *your* code. But in most ruby exceptions, the part of your code that triggered the error may be 10 lines deep into an 80-line stacktrace.
That’s why we give you two backtraces.
- Full backtrace: This is the normal Ruby backtrace. It contains everything.
- Application backtrace: A subset of the full backtrace, containing only the lines that appear to come from your app.
In the example below, you can see that the error originated from a rails view. That’s easy to see in the application trace. But it’s hard to see in the full trace, since it contains lots of extraneous information.
Note: If you’re not using Rails, or you have a strange directory structure, you may need to tell the gem what your project’s root directory is. You can do this by setting config.project_root in config/initializers/honeybadger.rb
If you prefer rails’ backtrace style to our own, you can easily switch. Just go to the backtrace and click “Rails Style”. Your choice will be saved in a cookie, so you won’t have to change it back every time.
You can quickly spot the HTTP method (get, post, put, delete) of a failed request. Just go to the detail page for the error you’re interested in and look next to the url.
Tip: To make things easy, we’ve color coded the methods. The more “dangerous” a method is, the closer to red it is.
Commenting on exceptions
Comments let your team have a discussion about an error…where the rest of the error info lives.
The easiest way to add a comment to an exception is to reply to the email notification. You can also add a comment from the web UI.
If you have more than one application server it can be important to know which one was the source of an error. This info is presented at the top of the error details page.