The DailyDrip team has been kind enough to ask me to do a guest post. I thought it would be interesting and perhaps useful to go over some techniques you can use to get more from your exceptions and error reports. Specifically, we're going to discuss several ways you can use error reports to create better experiences for your users.
When you think of exceptions, you probably think of an error message and a backtrace. That's what most languages give you, and that's enough in development. In production, however, you need a lot more context to understand what's happening.
For years monitoring tools like Ruby's exception_notifier gem and Honeybadger (my company) have allowed you to see the context around an error:
- GET and POST parameters for the failed request
- Cookies and other header values
- Environment variables
This is great, but these days it's only scratching the surface of what's possible.
As developers, we want to provide a good experience for our end users. Few things interrupt this like an application error. It's not only a nuisance to your user, it's confusing. They're left unsure if their order went through, their document was saved or their message sent. Wouldn't it be nice if your customer-service team could follow up with users who experienced the error and fix any issues that arose from it?
Most error monitoring systems offer some way to attach meta-data like user ids to error reports. Some, like Honeybadger, recognize common user-related fields and allow you to run reports on affected users and easily follow up with them via a GitHub issue, Intercom conversation or other third-party tools.
One of the most under-utilized sources of debugging information is the user themselves. Often, they're the only one who knows what they were doing before they triggered an error. Why don't we ask them?
It's not hard to add a feedback form to your error page. Some error monitoring tools provide a mechanism to display this form automatically and to attach any user feedback directly to the appropriate error report.
Even if you don't think this tactic will work with your end-users, it's still a great way to get feedback from your stakeholders or QA team during development.
If you haven't heard of FullStory, it's a service that lets you play back pixel-perfect reproductions of user sessions. If you find this a little creepy, you're not alone. But it can be a useful tool for understanding exactly what the user was doing when they triggered an error.
By attaching the FullStory session id to your error reports, you can look up the user's session and literally watch the error occur. At Honeybadger we detect FullStory session ids automatically and link you directly to the playback URL.
I hope this article gives you some ideas for how you can get more out of your error monitoring setup. If you have any questions, please don't hesitate to get in touch with me at firstname.lastname@example.org or @StarrHorne on twitter.
Description goes here if its a new author