Exploring Monitors: A New Way to Think About Alerts

[jas-kas]

Hi everyone 👋

We’re in the early stages of rethinking how alerting works in Sentry.

Sentry’s Alerts product sends millions of notifications to developers every day. As we continue expanding into new monitoring areas, we’ve been asking ourselves a few big questions:

• How can alerts be more actionable; helping developers debug problems faster, not just learn they exist?
• How can Sentry’s alerting model scale across all these monitoring verticals?
• And how do we make it clear to users what Sentry is monitoring for them?

One idea we’re exploring is introducing a unifying concept we’re calling Monitors.

All Alerts Have Issues

The philosophical shift behind Monitors is simple:

Anytime Sentry notifies you about a problem, there should be a Sentry Issue behind it, with the valuable context required to debug the issue.

Right now, Sentry can already generate issues from:

• Errors
• Uptime
• Crons
• Replays
• Profiles
• Spans

…but each of these is configured separately, often in different parts of the app. Few users see how they all connect.

The Monitors concept aims to unify that: giving developers one place to see everything Sentry is tracking for them, and how those monitors map to issues and alerts.

We’d Love Your Feedback

This is all early-stage exploration; nothing has shipped yet.
We’re looking for feedback from developers like you to help shape where this goes.

Specifically:

• Does the Monitors concept make sense?
• What do you think about alerts today: do you prefer a single, unified model or specialized configurations?
• Where would you expect to find monitors in the UI?

Your insights will help us make Sentry’s monitoring and alerting experience more cohesive and useful. Thank you!