In the screenshot below, we see a timeline showing a complete story of how the user encountered an error. First they loaded the page, typed their email address into the sign up form, validated the email, navigated to an onboarding page, and then the error occurred. This gives clear context on what caused the error and which component needs to be fixed.
Are your services secure?
In today’s world, you can hardly go a week without reading in the news about security breaches, malware, and more. We’ve already had headline news this year for Wanna Cry, and now there are dozens of copycat malware programs taking advantage of out-of-date systems. Think of all the services that your company uses from error monitoring to logging and APM. Some of them may be delivered by vendors and others set up by internal teams. Did your IT team evaluate these services to determine how secure they are? If not, you might want to reconsider the services you use or who can best deliver them.
Before merging was an option, if the default fingerprinting algorithm didn’t combine occurrences the way you wanted, then you needed to define custom fingerprinting rules. Custom fingerprinting rules require you to learn our JSON-based rule syntax, and that could be a deterrent against setting them up.
Now that you can easily merge errors via the UI, is there still value in setting up custom fingerprinting rules? Absolutely, and this blog post will explain why!
Hopefully you've had the chance to try out our latest feature, error merging. We've heard a lot of positive feedback from our users. They're especially excited to be able to easily merge and un-merge related errors. We thought it would be useful to share how the Rollbar team made this happen from a technical standpoint. If you're interested in the nitty-gritty of how we implemented error merging, read on.
I interviewed Todd Dampier, one of the engineers here at Rollbar who was instrumental in making error merging possible, about what was involved in engineering this feature.
I'm eager to share an insightful interview our friends at Changelog recently did with Andrew Childs, CTO at Clubhouse and Rollbar power-user. We're big supporters of the Changelog podcast and we asked them, to help us produce a handful of interviews with our customers. It's a fun project that lets us pull back the curtain and learn more about our customers processes for handling errors and deploying code. Read. Listen. Enjoy!
Featured in this interview: Adam Stacoviak, Founder & Chief Editor at Changelog, a podcast on software development and open source. Andrew Childs, CTO of Clubhouse, an easy-to-use project management tool for software teams.
Why resolving errors matters?
After fixing a bug, who is responsible for making sure if it really resolves the customer's problem? A lot of companies take a fire-and-forget mentality where the developer makes a code change, and they never think of the problem again until someone complains. Developers often assume that the fix will be deployed with the next release, that the fix will behave the same in production as it does in their development environment, and that it resolves every case uniformly. Only for the most urgent problems will they wait for the fix to hit production and then verify the improvement on the customer's side.
We're excited to introduce merging (and un-merging) of errors! Merging errors lets you combine multiple errors into one 'group' for easier management and more accurate metrics. All past and future occurrences of any merged errors will automatically be combined and grouped. Today's merged errors are tomorrow's error groupings. :-)
When you encounter a duplicated error, you'll want to create a new 'group'. Select one or more errors from the same environment in the error Items feed. Slide the toggle in the box above to 'Merge', set appropriate Level, Status, Owner, and Source values, enter a name for the new item, and click 'Merge'. Done, error merge success!