docs(alerts): move alert creation to its own page - #19067
Conversation
Split the per-option detail out of the Alerts index into a dedicated Creating an Alert page, and document the new "alert on all issues in all projects" source option. - Add docs/product/monitors-and-alerts/alerts/create-alerts.mdx covering sources, environment, triggers, filters, actions, and throttling - Trim the Alerts index to a high-level summary plus permissions - Point legacy /product/alerts/create-alerts/ redirects at the new page - Update inbound links from the Monitors and uptime pages Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
|
|
||
| - **Alert on all issues in selected projects**: Pick one or more projects. The Alert evaluates every issue in those projects, no matter which Monitor created it. | ||
| - **Alert on specific monitors**: Connect individual [Monitors](/product/monitors-and-alerts/monitors/) so the Alert only evaluates issues those Monitors create. Click **Connect Monitors** to search all Monitors, filter by project, and select the ones you want. Use **Edit Monitors** to change your selection later, or **Create New Monitor** to set up a new one. | ||
| - **Alert on all issues in all projects**: The Alert evaluates every issue in the organization. See [Alert on All Projects](#alert-on-all-projects) below. |
There was a problem hiding this comment.
I feel mixed about the section it links to below. It doesn't give that much information. I feel like you could simply add to this line here "This is the best choice for teams with simple alerting needs like feed channels in Slack or high level monitoring of newly detected issues." and be good.
| ### Alert on All Projects | ||
|
|
||
| Selecting **Alert on all issues in all projects** scopes the Alert to your whole organization instead of a set of projects. Sentry evaluates it against every issue in the organization and issues from projects created after you save the Alert are covered automatically. | ||
|
|
||
| This is the best choice for teams with simple alerting needs like feed channels in Slack or high level monitoring of newly detected issues. |
There was a problem hiding this comment.
I really don't think we need this. Added a suggestion above.
|
|
||
| ### If: Filters | ||
|
|
||
| Filters decide which actions will run when issue triggers occur. |
There was a problem hiding this comment.
Is this true? Doesn't a filter further narrow down which issues will qualify for the action to run? And Then decides which actions will run?
There was a problem hiding this comment.
every IF has a corresponding THEN (the action) technically IF is an "action filter". Actions only run on issues matching the filters. If this is confusing we can omit the statement as it's somewhat implied
|
|
||
| Filters decide which actions will run when issue triggers occur. | ||
|
|
||
| An Alert can have many **If** blocks and each **If** block evaluates filters matching with `all`, `any`, or `none` logic: |
There was a problem hiding this comment.
This also doesn't seem quite right. It looks like an Alert can have many "If/Then" blocks, but one If set can only use all, any, or none once. As in, I can't say in the same block: "If ANY of these filters match: issue category is outage, issue assigned to no one; AND If ALL of these filters match: Issue type is N+1".
I think what you're trying to say is that Alerts can have multiple If filters? Or Alerts can have multiple "If/Then" blocks?
There was a problem hiding this comment.
yeah this should be two statements maybe? Alerts can have many IF blocks.
As well,
each IF blocks support three types of filtering logic
|
|
||
| <Alert> | ||
|
|
||
| Event attribute, release, and frequency filters only apply to occurrence-based monitors (errors, N+1, and replay), and only to the **A new issue is created** and **An event is captured** triggers. The builder marks these filters with a warning icon. |
There was a problem hiding this comment.
Can we simplify this sentence? What is a non-occurence-based monitor?
Something more like:
Before the alert
There are a few different categories of filters: Issue Attributes, Frequency, Release, and Event Attributes.
Alert
Frequency, Release, and Event Attributes filters only apply to occurrence-based monitors (errors, N+1, and replay). Non-occurence-based monitors like ([what are these?]) can only be filtered by Issue Attributes.
Frequency, Release, and Event Attributes filters can only be used in combination with A new issue is created and An event is captured triggers. You will see these filters show a warning icon when they cannot be used.
There was a problem hiding this comment.
We should also move this alert up out of Issue Attributes. That confused me a lot.
There was a problem hiding this comment.
Also, the only "release" attributes I found were under "Event Attributes", which is also how it's documented on this page. I don't think we need to call those out separately from the category, if "Event Attribute" holistically cannot be used with non-occurence-based issues.
|
|
||
| #### Ticket Creation | ||
|
|
||
| Create a work item in an issue tracker, and use **these settings** on the action to configure fields such as project, issue type, assignee, and labels: |
There was a problem hiding this comment.
Why is "these settings" bolded? What settings?
There was a problem hiding this comment.
this would work better with an image - ticket creation has a sub-settings modal I'll clean up
|
|
||
| </Alert> | ||
|
|
||
| ### Add Multiple If/Then Blocks |
There was a problem hiding this comment.
Having this section here makes me think even more so that the If section is just misworded.
sfanahata
left a comment
sfanahata
left a comment
There was a problem hiding this comment.
I love the direction! I think we need to clean this up a bit before we merge. See comments and let me know if you want to chat.
Co-authored-by: Shannon Anahata <shannon.anahata@gmail.com>
Co-authored-by: Shannon Anahata <shannon.anahata@gmail.com>
Co-authored-by: Shannon Anahata <shannon.anahata@gmail.com>
Co-authored-by: Shannon Anahata <shannon.anahata@gmail.com>
Co-authored-by: Shannon Anahata <shannon.anahata@gmail.com>
Co-authored-by: Shannon Anahata <shannon.anahata@gmail.com>
Co-authored-by: Shannon Anahata <shannon.anahata@gmail.com>
Co-authored-by: Shannon Anahata <shannon.anahata@gmail.com>
Co-authored-by: Shannon Anahata <shannon.anahata@gmail.com>
4 participants
Split the per-option detail out of the Alerts index into a dedicated Creating an Alert page, and document the new "alert on all issues in all projects" source option.
DESCRIBE YOUR PR
Tell us what you're changing and why. If your PR resolves an issue, please link it so it closes automatically.
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: