Relevance and Ownership of Issues in Sentry 9

With Sentry 9, our goal is to increase the relevance of the information you see in Sentry in order to speed up your time to resolution, while also making the process of fixing application issues less annoying for everyone involved.

How are we accomplishing this?

We’ve increased our focus on ownership of issues: expanding your ability to control who owns what in your Projects, while expanding the power of teams and individuals to take action with that ownership.

Watch this short video and read on to learn more:

What do we mean by Ownership?

We began focusing on ownership with our Releases feature from last year, tying issues to the commits that surfaced them and suggesting owners for errors based on the engineer who last modified the now broken line. With our latest release, we’re building on this by increasing your ability to directly assign owners to different parts of your codebase based on file path or URL. We’ve also increased the functionality of teams: you can now assign multiple teams to a single Project, and can set entire teams as the owner of an issue.

The goal of this continuing commitment to ownership isn’t to blame specific engineers or teams for problems, but to instead ensure the issue ends up in the right hands as quickly as possible. That way, the person or team with the right context about the problem can fix it before there is even a need for customers or managers (or anyone else) to start pointing fingers.

What’s changed?

By default, issues associated with a particular project notify each user working on it. That may be perfect for a small project but, for a larger one (like, say, the entire front end of your site), there’s a good chance that not everyone wants a notification about each bug that comes through. This can potentially turn what should be a series of helpful alerts into white noise that ends up filtered into an email folder you rarely look at.

Let’s take a look at the new Issue Owner rules that we’ve added to each Project’s settings.

In your ownership rules, you define individual paths or URLs to be owned in whole by users or teams.

For example, you could add a rule in which any issue related to the billing page of your site is owned by the #money team.

Or you could define a path in which everything related to the Isildur pipeline belongs to team #arnor.

After paths and URLs are added, you can quickly edit them in plain text and can even add multiple owners, mixing teams and individuals together.

What if code isn’t assigned to anyone? Then errors associated with it will automatically continue to be seen by everyone unless you flip this switch. Maybe don’t flip this switch unless you’re confident everything is covered.

This is all made easier now by the new option to add multiple Teams to a project. Once a team is added via Project settings, it can both become owners and be tagged in messages, same as users.

To tag a team in messages, just use the # in front of the team’s name.

To assign an issue to a team, use the same dropdown you’ve previously used to assign an issue to an individual person.

These new ownership features in Sentry mean less noise and more noice.

We are so, so sorry for writing that last line.