How do I configure Sentry ownership rules so issues auto-assign to the right team/service?

Most teams don’t struggle to detect that something’s broken—they struggle to get the right person to own it fast. That’s exactly what Sentry Ownership Rules are for: turning raw events into clearly owned issues that auto-assign to the right team or service based on your code, services, or tags.

Quick Answer: Configure Sentry Ownership Rules from the Project settings using matchers like file paths, service names, or tags, and map them to teams or users. Once set, Sentry will use those rules to assign new issues (and alerts) to the right owners automatically, so triage doesn’t stall in “who’s on this?”

The Quick Overview

What It Is: Ownership Rules in Sentry let you define patterns (file paths, URLs, tags, services, etc.) that determine which team or user owns an issue.
Who It Is For: Engineering teams that want production issues and alerts to land with the right team/service without manual re-routing.
Core Problem Solved: No more “who owns this?” guessing. New errors, performance issues, and alerts show up already assigned to the right owner in Sentry and your issue tracker.

How It Works

At a high level, Sentry’s Ownership Rules match incoming events against patterns you define. When an event matches, Sentry assigns the resulting issue to the mapped owner (team or user) and uses that ownership for alert routing and integrations like Linear, Jira, GitHub, etc.

The flow looks like this:

You define rules:
In each project, you add Ownership Rules that match on code paths (path:), URLs (url:), releases, tags (tags[foo]:), or generic stack.module/stack.function patterns, and map them to @team-slug or user@example.com.
Sentry evaluates events:
When a new event comes in (error, transaction, etc.), Sentry checks its stack trace, tags, and metadata against your rules. The first matching rule(s) determine the owner(s).
Issues and alerts auto-assign:
The resulting issue gets an owner and can auto-assign to that team or user. Alerts and workflows (like “Create a Linear issue”) then use this ownership to route work where it belongs.

Step-by-Step: Configuring Ownership Rules for Teams and Services

1. Start with how your org is structured

Before you write rules, decide what “ownership” means in your world:

By code area: e.g., frontend/, backend/, payments/
By service: e.g., service:checkout, service:auth
By domain / product surface: e.g., /billing/*, /api/*

A good rule of thumb: mirror how you already slice ownership in your monorepo, microservices, or team structure.

2. Open Ownership Rules in your Sentry project

In Sentry, go to Settings → Projects → [Your Project].
Navigate to Ownership Rules (sometimes under “Issue Owners” or similar).
You’ll see a rules editor text area with guidance on supported syntax.

Each project has its own Ownership Rules, which is helpful if you want different rules per service or app.

3. Learn the Ownership Rules syntax

Sentry’s rules use a simple line-based syntax:

Basic format:
```
matcher:pattern owner
```
Owners can be:
- Teams: #team-slug (older notation) or @team-slug (preferred)
- Users: user@example.com or @username (if available)
For most orgs, use teams as the default; let the team’s internal processes decide who picks it up.
Common matchers:
- path: – match on file paths in stack traces
- url: – match on the request URL
- tags[<tag>]: – match on event tags (e.g., tags[service]:checkout)
- stack.module: / stack.function: – match on module or function names
- release: – match on release identifiers

Examples:

# All frontend code
path:src/frontend/* @web-team

# All backend API handlers
path:src/backend/api/* @backend-team

# Ownership by service tag (e.g., service:checkout)
tags[service]:checkout @payments-team
tags[service]:auth @auth-team

# Routes
url:/billing/* @billing-team
url:/admin/* @admin-team

# Specific module
stack.module:payments.handlers @payments-team

Rules are evaluated from top to bottom. Later rules can add additional owners but won’t remove owners added by earlier matches.

4. Map issues to services via tags

If you already have services defined in your code, let Sentry piggyback on that by adding a service tag or similar.

Instrument your code:

# Python example
import sentry_sdk

sentry_sdk.init(
    dsn="YOUR_DSN",
    traces_sample_rate=1.0,
)

with sentry_sdk.configure_scope() as scope:
    scope.set_tag("service", "checkout")

Then in Ownership Rules:

tags[service]:checkout @checkout-team
tags[service]:auth @auth-team

Now any error/transaction with service:checkout is owned by @checkout-team automatically.

5. Use file paths for monorepos and layered apps

If your monorepo is already structured by domain, use path::

path:apps/web/* @web-team
path:apps/mobile/* @mobile-team
path:services/payments/* @payments-team
path:services/notifications/* @notifications-team

Ownership is based on stack trace frames. When an error’s stack trace includes services/payments/*, Sentry assigns the issue to @payments-team.

6. Tie ownership to routes and URLs

For user-facing issues, routes are often more intuitive:

url:/checkout/* @checkout-team
url:/user/settings/* @account-team
url:/api/v1/payments/* @payments-team

This works well when URLs are strong indicators of which service or team should own the bug, especially in frontend-heavy apps.

7. Configure auto-assignment behavior

Ownership Rules determine “who owns this.” Auto-assignment decides “who gets this issue assigned.”

In your project:

Go to Settings → Projects → [Project] → Issue Owners / Ownership.
Look for Auto-Assignment options, such as:
- Assign to issue owner (team/user from ownership rules)
- Assign to commit author (via Suspect Commits / Code Owners, if configured)
Choose the behavior that fits your workflow:
- Team-first approach: Assign to @team-slug and let the team distribute internally.
- Code-owners approach: Combine Ownership Rules with CODEOWNERS (if GitHub/GitLab integration is enabled) to route directly to individuals.

Auto-assignment keeps your backlog from turning into a pile of “Unassigned” issues that everyone ignores.

8. Connect ownership to alerts and issue trackers

Ownership only pays off if it changes who actually gets interrupted.

Alerts:
When you create an alert rule (errors or performance), use the option to notify the “Issue Owner.” That way the same Ownership Rules govern both who owns the issue and who gets paged/emailed/slacked.
Linear / issue trackers:
With the Linear + Sentry integration, when an issue is created from a Sentry error, ownership helps route correctly:
- The Linear issue creation can be triggered from the right team’s workflow.
- Resolution in Linear can sync back to Sentry and resolve the issue.
Ownership isn’t strictly required for the integration, but it keeps “who should create and manage this Linear ticket?” obvious.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Ownership Rules Engine	Matches events on file paths, tags, URLs, modules, and more.	Automatically routes issues to the right team/service.
Team-Based Assignment	Assigns issues to `@team-slug` or specific users based on rules.	Eliminates triage bottlenecks and “unowned” incidents.
Alert + Workflow Routing	Uses ownership to drive alerts and issue tracker integrations.	Ensures the right people are notified and tickets sync cleanly.

Ideal Use Cases

Best for microservices and distributed systems:
Because you can tag each service (service:auth, service:checkout) and map those tags to specific teams. When one service fails, only that team gets the noise.
Best for monorepos with clear folder structure:
Because path: rules let you align ownership to repo directories—apps/web, services/payments, etc.—without rewriting your org chart.

Limitations & Considerations

Ownership is project-specific:
Rules live at the project level. If you expect a global set of rules across multiple projects, you’ll need to replicate (or script via API) your Ownership Rules.
Garbage in, garbage out:
Ownership Rules depend on good telemetry: meaningful stack traces, consistent tag usage, and stable URL patterns. Invest a bit of time instrumenting tags and making sure source maps/symbols are uploaded so frames are accurate.

Pricing & Plans

Ownership Rules and issue assignment are available across Sentry’s core plans. You pay based on event volume (errors, transactions, replays, logs, etc.) and can add Seer as an AI debugging add-on per active contributor.

Developer / Team plans: Best for teams needing code-level monitoring with a few projects and straightforward ownership (e.g., by service or repo path).
Business / Enterprise plans: Best for organizations needing broader governance (SAML + SCIM on Business+), more projects and dashboards, plus more complex ownership across many teams and services.

For exact quotas and limits, check your plan details in Sentry or on sentry.io/pricing.

Frequently Asked Questions

How do I test that my Sentry ownership rules are working correctly?

Short Answer: Trigger a test error or transaction that should match a rule, then check the resulting issue’s owner in Sentry.

Details:
After editing Ownership Rules:

Save your rules in the project’s Ownership page.
In your app, trigger a controlled error:
- From a route/path you matched (/billing/test-ownership)
- Or in a file path you matched (services/payments/test.py)
- Or with a tag you matched (e.g., scope.set_tag("service", "checkout"))
In Sentry, open the new issue and look at the Issue Owners and Assignee fields.
If ownership isn’t what you expect:
- Confirm the event actually has the tag/path/URL you’re matching.
- Check rule order and ensure there are no typos in tags[service]: keys or team slugs.
- Adjust rules and repeat until the new issues land with the right team.

What’s the difference between Ownership Rules and CODEOWNERS / Suspect Commits?

Short Answer: Ownership Rules are Sentry-side routing logic; CODEOWNERS and Suspect Commits tie issues back to source control and specific commit authors.

Details:

Ownership Rules:
- Defined in Sentry per project.
- Match on runtime data: stack traces, tags, URLs, releases.
- Result: “This issue belongs to @team-x and/or @user-y.”
CODEOWNERS / Suspect Commits:
- Defined in your repo (CODEOWNERS) and read via Sentry’s source control integration.
- Match issues to files and commit history to suggest who likely introduced the change.
- Result: “This person probably caused this issue.”

They work well together: Ownership Rules ensure every issue has a team owner; CODEOWNERS and Suspect Commits help you find the right individual or reviewer inside that team.

Summary

Configuring Sentry ownership rules so issues auto-assign to the right team/service is mostly about codifying what you already know: “this folder belongs to that team” and “this service belongs to that group.” Once you translate that into path:, tags[service]:, and url: rules, Sentry will attach clear owners to new issues, auto-assign them, and route alerts and tickets accordingly. Less time arguing about who owns a bug, more time fixing it.

Next Step

Get Started