Sentry: Three Best Practices for Error Management
Triage Issues
One best practice is to triage alerts from Sentry. These alerts are configurable and you can manage them by visiting the alerts page. This page allows you to set up rules with triggers and filters. By default Sentry sends notifications for all new issues. You might want to create a custom rule for when there is a spike in any of the issues so that you are aware and quickly jump on it.
During the review phase, data collected by Sentry is reviewed. This data includes call stack, contexts (browser, devices, etc.), breadcrumbs, tags, environments, and releases.
Call stack has more weight than others because it tells you where an error occurs in the code. I generally find breadcrumbs to be useful because they give you logs that lead up to the error. Tags are also helpful as they tell you what the environment is.
After you have carefully reviewed the data, the next step is assigning an owner to the Sentry issue. The best owner is someone who has recently worked on related code or otherwise has the most context on the problem at hand.
Issue Merging
Sentry has algorithms to group similar events into the same issue. This algorithm does not work flawlessly. Sentry tries to compute a hash for each event. Events with the same hash are grouped together.
When a stack trace is provided, it is fed into a hash function. If a stack trace is not provided, it will use either an exception or message from the event. Sometimes two stack traces are the same, but a difference of a few lines would mean the hashes would be different as shown below.
Because the issues above have the same root cause, we should merge them. Sentry gives us a way to manually merge issues together. To do this, you have to select two or more issues and click the merge button.
Sentry Standing Meetings
I am part of the Platform team at Broadlume. One of the processes that we implemented is having a recurring meeting with every engineer in the team to review and discuss Sentry issues. This meeting lasts about one hour on average.
The process goes like this. Anyone can bring up an issue that requires attention during the meeting. As a team, we discuss and review each issue. When necessary, we will walk through code to figure out the best solution.
There are times when we can’t fix the issue simply by changing code. So we make action items to follow up after the meeting. Action items include reaching out to a Product Manager or other stakeholders about an issue and describing in detail what the issue is and why it is happening.
What I learned from being more transparent is that it invites others to ask questions and help gather the information and send it to the right contact to address the issue. After all immediate issues have been discussed, we walk through the issues list and follow the triage process as explained above.
Happy triaging! I’d love to hear about your Sentry or other error tracking and management tool experiences in the comments below. Thanks for reading!
