[[左メニューのアラートに移動し、設定したアラート一覧を見ます。新しいアラートを作成するには、”Create Alert "をクリックします。]]

[[ここではissueアラートを設定してみます。Sentryのけるissueとは、類似のスタックトレースを持つエラーをグループ化したものです。開発者のためにSentryはエラーを自動的にグループ化することで、データのノイズを減らします。]]

[[ここで、どの環境か（本番環境、ステージング環境、テスト環境など）の選択を忘れないようにしましょう。デフォルトはすべての環境です。緊急度やエラー発生後のワークフローは、例えば本番環境のアラートとQA環境のアラートでは異なるため、このフィルタが役に立ちます。Sentryでは、プロジェクト毎にアラートを設定することもできます。]]

[["When"条件（またはトリガー）を設定します。 "When "条件（またはトリガー）は、issueに対してどのような種類のアクティビティを監視するかを指定します。トリガーは任意です。トリガーを選択しない場合、"When"条件はデフォルトで満たされ、つまり、すべてのイベントがこの条件を満たすことになります。]]

  ステータス変更の設定 - issueの状態が変更されたときのトリガーを設定

新しいissueが作成されたとき

issueが解決済みから未解決に変わったとき

issueがarchivedからescalatingに変わったとき


[[ノイズを減らすために、issueの頻度条件を設定します。アラートが増えすぎないように慎重に検討して設定しましょう。]]

頻度（フリークエンシー）に基づくトリガー

 イベント数トリガー：よく利用されます。必ずしも頻度が全てではなく、低い頻度で発生する重大なエラーもありえます。

影響を受けたユーザー数：非常に少数のユーザーから大量のエラーが発生することもあるため、エラーの頻度よりも、ユーザーに対するアラートの方が重要な場合があります。

影響を受けたセッションの割合（%）：セッションをキャプチャするようにプロジェクトを構成している場合、issueがユーザーセッションの何%以上でアラートを出す、という設定ができます。


Want to make guides like this in seconds? Yes, it's really that fast.