Open
Conversation
Add a practical alerting guide covering common routing strategies, noise reduction techniques, fixed vs. change alert thresholds, and three concrete use case walkthroughs for gaming, SaaS, and mobile. Draws from and supplements the alerts best-practices page, which is being retired. Co-Authored-By: Claude <noreply@anthropic.com>
The heading in alert-types.mdx is "Uptime Alerts" which generates #uptime-alerts, not #uptime-monitoring. Co-Authored-By: Claude <noreply@anthropic.com>
…iage link The states-triage page has no heading generating this anchor. Link to the page itself instead. Co-Authored-By: Claude <noreply@anthropic.com>
Add a practical guide covering cron and uptime monitoring strategy: what to monitor, how to configure checkin margins and max runtime, noise reduction via environments and ownership, and three concrete use case walkthroughs for gaming, SaaS, and mobile. Co-Authored-By: Claude <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
sfanahata
reviewed
Apr 24, 2026
Comment on lines
+13
to
+21
| Sentry has three alert types. Each serves a different purpose: | ||
|
|
||
| | Type | Triggered By | Best For | | ||
| | ---- | ------------ | -------- | | ||
| | [Issue alert](/product/alerts/alert-types/#issue-alerts) | An individual issue meeting specified criteria | New errors, regressions, issues affecting specific users or tags | | ||
| | [Metric alert](/product/alerts/alert-types/#metric-alerts) | A project-level metric crossing a threshold | Crash rates, error rates, transaction volume, p95 latency | | ||
| | [Uptime alert](/product/alerts/alert-types/#uptime-alerts) | HTTP check failing | Endpoint availability | | ||
|
|
||
| Most teams start with issue alerts, then add metric alerts for high-level health signals and/or uptime monitoring for critical endpoints. |
Contributor
There was a problem hiding this comment.
I don't think we care about this distinction anymore. If you navigate through the new UX (you can find it in sentry.sentry or demo.sentry), you'll see that it's pretty "type" agnostic. You can definitely set up alerts based on issue type or category, and that's also really useful, and probably should be mentioned somewhere, but this reads like it's based on the old paradigm. Check it out https://demo.sentry.io/monitors/alerts/?project=-1&statsPeriod=7d
sfanahata
reviewed
Apr 24, 2026
| - **Tag filters**: Scope alerts to what matters, like `customer_type:enterprise` or `environment:production`. Create your own tag filters in [project settings](https://sentry.io/orgredirect/organizations/:orgslug/settings/projects/:projectId/tags/). | ||
| - **Age filter**: Use `The issue is newer than X days` to avoid repeated alerts on old, known issues. | ||
| - **Frequency floor**: Use `Issue has happened at least {X} times` to filter one-offs that may resolve themselves. | ||
| - **Latest release only**: Use `The event is from the latest release` to focus post-deploy monitoring. |
Contributor
There was a problem hiding this comment.
Suggested change
| - **Latest release only**: Use `The event is from the latest release` to focus post-deploy monitoring. | |
| - **Latest release only**: Use `The event is from the latest release` to focus post-deploy monitoring. Learn about setting up [releases](https://docs.sentry.io/product/releases/) |
sfanahata
reviewed
Apr 24, 2026
Comment on lines
+43
to
+59
| ### Use Change Alerts for Fluctuating Metrics | ||
|
|
||
| Fixed thresholds work when you know what "bad" looks like. But some metrics are seasonal, like error counts are naturally lower on weekends and higher during launches. A fixed threshold requires constant manual adjustment. | ||
|
|
||
| Use **change alerts** when: | ||
| - Traffic patterns vary significantly (daily, weekly, by region) | ||
| - You're growing fast and thresholds go stale quickly | ||
| - You don't yet know what "normal" looks like for a new feature | ||
|
|
||
| A change alert fires when a metric is X% higher than the same window from one week ago — no manual tuning needed as baseline traffic grows. | ||
|
|
||
| Use **fixed thresholds** when you have a clear definition of "bad": | ||
| - Crash-free session rate drops below 99% | ||
| - Any enterprise customer is affected by an error | ||
| - Response time for `/checkout` exceeds 500ms | ||
|
|
||
| Most teams use both: fixed thresholds for absolute failure conditions and change alerts for relative degradations. |
Contributor
There was a problem hiding this comment.
Thresholds are much more of a thing on monitors now. There are a few "change" attributes still available, but this is not quite the way to talk about that kind of additional thresholding for alerting.
Contributor
|
@coolguyzone I think you're still referencing old UX. Can you take another pass at the current UX? You can find that in the demo org. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DESCRIBE YOUR PR
See new guides!
https://sentry-docs-git-coolguyzone-featmonitors-guide.sentry.dev/guides/alerts/
https://sentry-docs-git-coolguyzone-featmonitors-guide.sentry.dev/guides/monitors/
IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes:
LEGAL BOILERPLATE
Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.
EXTRA RESOURCES