How to fix errors in production with GitHub and Sentry

This post was written by our partners at Sentry—an open source error tracker that helps you prioritize, identify, reproduce, and fix issues.

Install Sentry from GitHub Marketplace or the Student Developer Pack

Sometimes bugs slip through even the most diligent of code reviews. Putting out fires can disrupt your flow, forcing you to comb through logs and user-submitted screenshots. In the meantime, your users are left with an enigmatic 500 page. To help your team get from error to fix as efficiently as possible, try Sentry—an open source project under the BSD license. Sentry alerts you to the problematic line of code, pinpoints the commit and author likely responsible, and lets you resolve the error by including fixes ISSUE_ID in your commit message.

It starts with an overlooked edge case during an otherwise routine deploy. When a new deploy introduces an error, your team gets alerted and kicks off the familiar workflow of triaging, assigning, reproducing, and, finally, fixing the error. Sentry integrates neatly into your GitHub development flow, providing you with timely information and the rest of your team with visibility into every step.

Triage

Teams with rapid release cycles are familiar with sorting through dozens of active issues to assess each error’s potential scope and severity. To speed this up, Sentry groups errors by their stack traces, highlighting the number of users impacted, frequency of error, and any custom tags—like whether the error impacts billing code—allowing engineers to prioritize the bugs with the largest potential impact.

Assign

Once you establish priority, you’ll need to assign a developer with plenty of context, typically the one that introduced the error, to the issue. To narrow down the pool of potential assignees, Sentry locates the commit and the author likely responsible for the error, then suggests an owner—no need to dig through git blame to find the best person for the job. You can also link Sentry issues to GitHub issues to give non-engineering product teams visibility as your team starts resolving the issue.

Reproduce

Most errors come from unexpected user behavior and leave you asking, “How did this even happen?” Fixing these more complicated errors takes more than a stack trace. You need to understand what the user or application was doing when the error occurred. Sentry collects a breadcrumb trail of user actions leading up to an error and, when available, a snapshot of the application’s variables, browser or OS, environment, and release. With these details, you can more easily reproduce errors without needing to further inconvenience the users that experience them.

Fix

After your team fixes a bug, it’s important to track the fix as it’s deployed and resurface the issue if it doesn’t work. Similar to how you can close GitHub issues from a commit, you can mark Sentry issues as resolved using the same commit keywords with a Sentry short-id, like fixes JAVASCRIPT-E41. As the commit is deployed, Sentry will mark the issue as resolved and silence future errors coming from older releases. However, if the issue re-appears, Sentry will mark it as a regression and alert you.

Sentry is part of the GitHub Developer Program and launched their app in GitHub Marketplace last month. If you’re working on an integration using the GitHub API, you’re welcome to join the program as a business or an individual no matter what stage of the development process you’re in.

Written by

Eric Feng

@ehfeng