docs(priority-alerts): Add docs for high priority alert conditions (#…

…9732)

* Add docs for high priority alert conditions

* Update docs/product/alerts/best-practices.mdx

Co-authored-by: Matt Duncan <14761+mrduncan@users.noreply.github.com>

* Update docs/product/alerts/create-alerts/issue-alert-config.mdx

Co-authored-by: Liza Mock <liza.mock@sentry.io>

* chore(issues): "high-priority" -> "high priority"

---------

Co-authored-by: Matt Duncan <14761+mrduncan@users.noreply.github.com>
Co-authored-by: Liza Mock <liza.mock@sentry.io>
Co-authored-by: Matt Duncan <matt.duncan@sentry.io>

docs/product/alerts/best-practices.mdx

@@ -37,6 +37,7 @@ Below, we describe best practices for setting alerts using the following frequen
 
 One way to keep alerts from becoming too noisy is to use filters, or “if” conditions, as part of your alert configuration. Below, we describe best practices for setting alerts using the following noise-reducing filtering options:
 
+- **Prioritize high priority issues**: If you're getting too many notifications about non-error or low priority issues, add the 'high priority' condition to your alert configuration. That way, you'll only get alerts for high-priority issues.
 - **Prioritize using tags**: Filter issue alerts based on important tags, such as `customer_type=enterprise` or `url=/very/important/page`. You can find the list of tags available in your project under **[Project] > Settings > Tags**. The list is an aggregation of all tag keys (default and custom) encountered in events for that project.
 - **Prioritize new issues**: If you're frequently getting alerted about old issues, filter your alerts to issues created in the last few days using the `The issue is older or newer than...` filter.
 - **Filter transient issues**: Many issues exhibit a short burst of events that can trip your frequency-based alerts. To filter out these issues, use the `Issue has happened at least {X} times` filter.

docs/product/alerts/create-alerts/issue-alert-config.mdx

@@ -26,6 +26,8 @@ Specify which project will use this particular alert rule. The created alert rul
 - The number of events in an issue is more than a certain number or has a higher [percent change](#change-alerts) in an interval
 - The number of unique users is more than a certain number or has a higher [percent change](#change-alerts) in an interval
 - An issue affects more than [\{X\} percent of sessions in \{time\}](#percent-based-alerts)
+- A new issue is marked as [high priority](/product/issues/issue-priority/)
+- An existing issue is marked as [high priority](/product/issues/issue-priority/)
 
 Triggers are optional. If you don’t select a trigger, the "When" conditions are considered met by default. That is, _all_ events will meet this condition.