Blog |

Turning Errors Into Action: How and Why Resolving Errors Matters

Turning Errors Into Action: How and Why Resolving Errors Matters
Table of Contents

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.

Let's face it, verifying the resolution of issues in production is a chore and takes away from developer productivity. Often, the developer has already moved on to other problems by the time fixes are deployed. In many companies that don't have continuous deployment, developers have little control over when releases get shipped. If you're using an issue tracking system, the developer's job usually ends when the code is written and merged. Even if developers wanted to go back and verify the fix works, they may not have the proper tracking tools to do so.

Who is accountable for ensuring that bugs are fixed on the customer side? The support or product management teams will complain if it doesn't work as expected, but why should they be responsible? They have better things to do than follow up on dozens of bugs that are filed every week.

You're forcing customers to report unresolved problems if no one else is checking. This results in more support tickets, bad experiences and lower satisfaction scores, which is only the tip of the iceberg. Only a small percentage will bother filing a support ticket and most suffer in silence. If problems happen consistently, your customers will be less likely to recommend your product to others, and may eventually churn out. While checking costs you time, making your customers do it can cost way more.

Resolving issues doesn't have to be painful or take a lot of time. Rollbar has created a better way which automatically monitors production code changes and can track each error to resolution. It can save you time and lets you deliver a better customer experience.

Here's 6 ways to quickly resolve errors in Rollbar:

1. Resolve errors and automatically track regressions in the app

Rollbar allows you to mark errors as resolved several different ways, but the simplest is by clicking the resolve button in the web app. You can see the resolve button in the screenshot below, which is colored green.

Item screen

The real intelligence behind this feature is that it will continue to track this item in the background to ensure that it is really resolved in production. If this item occurs again, Rollbar will reactivate it and can notify you immediately. errors can become reactivated if you thought you had fixed the error in production, but failed to deploy the change, you missed a use case in your code, or there was a later regression that caused it reactivate.

The saves your team time because you don't have to go back and monitor whether your code change really works in production. You just have to deploy it, resolve the item, and trust Rollbar to notify you if the error returns.

2. Resolve errors in a code version

What if you've made a code change to fix an error, but it hasn't been rolled out yet? If you resolve that item now, it will just reactivate. Instead, you want to resolve that item when the change is live.

If your application is a mobile app or single page application, this feature is a must-have because different clients could be running different versions at the same time. Without it, the item will keep getting reactivated when the error happens to users who haven't updated to the latest version of the app. This also applies to large server-side systems, where it's common for deployments to gradually roll out across multiple nodes or environments, so you may be running two versions in parallel.

Rollbar has a little bit of magic that allows you to resolve an error in a code version. It will wait for the fixed version to go live before notifying you again. To use this feature, just enter the version that contains the fix when you resolve an item in the web app. This will prevent the item from becoming reactivated in earlier versions.

Resolve in version UI

Rollbar will know when your fixed version is live by looking at the code_version parameter that you pass when you set up your notifier. Here is an example of JavaScript code passing the version. It happens to use the SHA from the GitHub commit.

var _rollbarConfig = {
    # ... other configuration
    payload: {
        environment: "production",
        version: "3da541559918a808c2402bba5012f6c60b27661c"
    }
};

This saves you more time because you don't have to keep track of when a code change goes live in order to monitor whether it's been fixed. Rollbar will automatically track these changes and notify you if the error occurs again when the new code version is live.

Learn more in the resolve-in-version docs

3. Resolve in a commit message

An even easier way is to resolve the item when you commit code that fixes the issue. This way, you don't have to manually resolve or paste the version number in Rollbar's webapp. Rollbar can integrate with your source control system to get all the commits when you deploy. For example, in your commit message, just add the “resolve” keyword and then paste the link to the item:

resolve https://Rollbar.com/demo/demo/errors/315/

When you do a deployment, make a call to Rollbar's REST API to notify it of the revision that you are deploying. The revision should be the git SHA for the latest commit. Rollbar will get a list of all the commits that have been made prior to your latest revision. It will then resolve any errors that have been referenced in the commit messages. For example, if you deploy using bash scripts, you could add the following commands to notify Rollbar:

ACCESS_TOKEN=POST_SERVER_ITEM_ACCESS_TOKEN
ENVIRONMENT=production
LOCAL_USERNAME=whoami
REVISION=git log -n 1 --pretty=format:"%H"

curl https://api.rollbar.com/api/1/deploy/ \
  -F access_token=$ACCESS_TOKEN \
  -F environment=$ENVIRONMENT \
  -F revision=$REVISION \
  -F local_username=$LOCAL_USERNAME

You only have to set up this bash script once, and from then on, you can easily resolve in commit messages. Similar to resolving errors in the web app, Rollbar will not reactivate errors for clients using an older code version. This way, you know that if an item reactivates in your Rollbar dashboard, it is a real regression and is worthy of your attention.

Learn more in the resolve-via-commit docs

4. Merge errors that are duplicates

If an error or item in your item screen is a duplicate of another, you should merge them. You can even merge errors that have different messages but the same root cause. This prevents overload on your dashboard page and alerts. By default, rollbar will automatically merge or group occurrences of errors that have the same fingerprint. You can change the algorithm used to group these occurrences. Alternatively, you can manually merge them on the errors screen. Just select the duplicates and then click on the merge button as shown in the screenshot below.

Merge duplicates

Learn more in the grouping docs

5. Mute errors that you can safely ignore

I know what you're thinking, “It's great to be notified about errors I care about, but what about all the other noise?” We know you don't want to be distracted by unimportant information. That's why we added the ability to mute errors you don't care about. You can see the mute button in the screenshot above to the right of the resolve button.

Muting errors will hide them from your dashboard and item view, and Rollbar will not send you notifications. Furthermore, thanks to our grouping rules you only have to mute one occurrence of an error and all future occurrences will also be muted. Just remember to use this power wisely! People tend to fix what they see, so if you intend to fix it, keep it visible!

6. Auto-resolve old errors for a clean view

We always want to prioritize and focus our efforts on the most critical issues. What about all the one-off errors that build up over time? These could be rare edge cases, operational issues that have since gone away, or errors that were fixed but the team forgot to mark them as resolved. We don't want to distract our team or spend a lot of time clearing them out, so we can ask Rollbar to automatically resolve them.

Rollbar can automatically resolve errors under two conditions. The first is automatically resolving errors that have not been seen for several days:

Automatically resolve old errors

The second is automatically resolving errors when a deploy is made. This is useful when you only want to track issues that are happening in your latest production build.

Automatically resolve on deploy

Rollbar still tracks the history of each of these errors so if they come back in the future, you'll still have a record. This prevents less important errors from distracting your team, so they can focus on the most critical issues.

Reactivation notifications and dashboard give confidence

When you resolve an item, you want to have confidence that it is fixed and will not return. Unfortunately, not all of us have psychic abilities to know what problems will happen in the future. Fortunately, Rollbar can monitor each resolved item and notify you if it is reactivated. This saves you a lot of time because you don't have to go back and check whether the problem is fixed, you can just rely on Rollbar to notify you.

Rollbar offers many channels for notification including email, Slack, HipChat, and PagerDuty. Additionally, you can see all the new and reactivated errors on your dashboard. It's broken down into errors from the last day and the last week. If you just did a deployment earlier today, check the last day category. If you do weekly sprints, you can see errors from the last sprint in the last week category.

Reactivation notifications

Follow up with affected customers to build trust

Following up with customers is probably one of the most valuable and most overlooked parts of resolving problems. It's particularly important for high-value customers who took the time to report a problem, or for large problems that affect many customers. Customers understand that companies have problems from time to time, and they are willing to forgive if you show that you listen and take them seriously. Also, if you develop a good relationship where you have an open door, they will be more willing to share feedback because they see a return on the investment of their time, and they may even become an advocate or spokesperson for your product.

Of course, following up takes time, but it's much easier now than it used to be. Without Rollbar, you might see a bunch of errors in your logs, or a dip in your New Relic or business metrics dashboard. That's because the sources don't record the customer's information, and may sample the data so you don't have a complete picture.

Rollbar gives you a complete record of every customer affected by each error. You can quickly query and export a list of all affected customers, and then copy them into your email automation tool. If it was a particularly disruptive problem, your marketing team can even offer something special to turn it from a negative to a positive experience. You'll know you did a good job when you see the “thank you” responses come in.

People affected

Get to “Rollbar zero”

Some of our best customers make it a point to review and resolve all the errors in their Rollbar dashboard on a regular basis. The reason is because when new errors pop up, they want to have instant visibility so they can react quickly and resolve them before more customers are affected. They don't want to have unimportant errors clogging their view, nor do they want to automatically resolve and potentially miss issues. One customer makes it fun by throwing a “Rollbar party”. They get their developers in a room and knock out errors together.

Conclusion

The net is that Rollbar helps you keep your customers and make them happy. You'll have better visibility into errors affecting customers, and you'll be able to track that they are actually resolved in production. It also streamlines the workflow for your development team because Rollbar will automatically track resolution without requiring anyone to remember and follow up later. When you mark a critical item resolved in Rollbar, you can trust that it improves customer experience.


If you haven’t already, signup for a 14-day free trial of Rollbar and let us help you take control of impactful production errors. 🙂