ユーザーより先に問題を把握する
ダッシュボードをリロードしながら回帰を見つけようとするのはやめましょう。誰も見ていないときでも把握しておきたいシグナルがあれば、アラートを設定して、普段使っている場所に通知を届けましょう。- メール：通知すべき担当者へ。
- Slack：インシデントに直接ジャンプできるボタン付きのリッチメッセージ。
- Webhook：PagerDuty、Opsgenie、または独自のエンドポイントへの JSON POST。受信側が信頼できるよう任意の署名を付与可能。
- ダッシュボード内：ルールを調整中でまだ誰にも通知したくないときのための、静かな通知。
JSON ではなくフォームでルールを作成する
「壊れている」状態をフォームで記述するだけで、Failproof AI Observability が内部ルールを生成します。JSON 仕様はフォームが生成したものにすぎないため、ルールの内容を理解するために読むことはあっても、直接入力することはほとんどありません。
エラーページで障害を確認中ですか？各行に + アラート ボタンがあり、その障害を再度検出するようにプリフィルされた状態で同じフォームが開きます。これにより、今トリアージしたインシデントが次回の通知トリガーになります。
場所： アラートは
/<org-slug>/alerts にあります。ルールの作成・編集・削除・テストには alerts:write が必要で、閲覧のみなら alerts:read で十分です。受信者ピッカーには組織メンバーが名前で一覧表示されるため、フォームを離れることなく特定の担当者に通知できます。
本当に必要なときだけ通知する
1回の悪い計測値で起こされるべきではありません。M of N ノイズフィルターは、アラートが実際に通知を送る前に、直近の数回のチェックのうち何回失敗する必要があるかを制御します。3 of 5 に設定すると、直近5回のチェックのうち3回しきい値を超えた場合にのみ発火するため、不安定なシグナルによる誤報を防ぎます。デフォルトの 1 of 1 のままにすれば、最初のしきい値超過で即時発火します。また、シグナルの実際の変化速度に合わせて、1m・5m・15m・1h のプリセットからルールの実行頻度を選択できます。アラートが発火したときの動作
しきい値超過によってインシデントが作成され、チャンネルに1回通知が送信されます。その後、チームはインシデントを認識し、担当者を割り当て、議論し、解決します。これらはすべて整理された帰属記録に対して行われます。このトリアージワークフローには専用のページがあります：インシデントをご覧ください。関連ページ
- インシデント：発火したアラートをオープンから確認済み、解決済みまで追跡する。
- エラートラッキング：エージェントの障害をグループ化し、ワンクリックでアラートに昇格させる。
- ダッシュボード：アラートのしきい値の元になっている共有ボードを確認する。
- CLI とエージェント：ターミナルからアラートを作成してインシデントを確認し、CI にスクリプトとして組み込む。