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.
Developing and maintaining user facing software is a challenge and a very distracting one at that. :-) Often times it can be difficult trying to stay focused on what matters most. It can be hard to tell what's really broken and why, with dozens of alerts notifying you every other minute. Volatile... The client-side being one of the most volatile of them all.
You're two weeks into using Rollbar. You've watched in amazement as issue after issue comes in without a single customer complaint to accompany them. How did you ever find errors before!?
Now that your unresolved errors have drastically decreased, you've started to notice a handful of Rollbar items that all seem to be exactly the same issue. Maybe you've been notified that your UI has exceeded the maximum call stack when calling a particular function. And in one case you found out that your database is actually missing several columns which got grouped into a single error.
What's a new Rollbar user to do? Here's 6 steps to help you improve your error grouping in Rollbar: