Watches

Watch はスケジュールで動き、何かがおかしいときだけ口を開くチェック。デフォルトで沈黙。Watch を開きません。Watch があなたのところに来ます。

要点は、「毎朝ログインしてすべて問題ないか確認する」儀式を置き換えること。Watch をセットアップし、忘れ、数値が動いたら肩を叩いてくれます。

Watch の解剖

4 部分:

• クエリ — 実行ごとに単一値または小さな結果セットを生成する SQL / Python / フェッチ。
• 条件 — その値に関するルール。> 0.03、< -15、昨日と異なる、欠落。
• スケジュール — チェック頻度。5 分ごと、1 時間ごと、毎日 08:00。
• 通知 — アラート送信先。メール、Slack、webhook、または複数。

オプション:

• クワイエットアワー — 設定したウィンドウ中は抑制。
• デバウンス — 発火前に N 分間条件が true である必要。
• 確認 / スヌーズ — 一定期間更なるアラートを一時停止するユーザーアクション。

Watch の作成

最も簡単な経路: Agent に頼む。

> 直近 24 時間で返金率が 3% を超えたら通知して。

Agent は:

1. クエリを書く（直近 24 時間の返金 / 注文）。
2. 条件を選ぶ（> 0.03）。
3. スケジュールを選ぶ（時間単位 — ローリング 24 時間データで意味のある最速）。
4. どこに通知するか聞く。
5. Watch を作成。

Agent 答えの Keep バーから ＋ Watch で作成も、サイドバー → Watches → + New で手動構築もできます。

条件

Watch は以下の条件タイプをサポート:

タイプ	例	備考
閾値	refund_rate > 0.03	最も一般的。
相対	今日 vs 7 日平均、20% 以上ずれ	季節データに有用。
欠落	直近 1 時間に行なし	データパイプラインに有用。
トレンド	連続 3 日下降	緩い下降に有用。
異常	95% 信頼区間外	Python の検出を使用。閾値が分からないときに良い。

Agent はあなたのフレージングから 1 つを選びます。Watch 設定でタイプを切り替えられます。

デバウンス

アラートはまれなとき最も大きい。デフォルト挙動:

• 条件が true になったとき一度発火。
• true のままの間は沈黙。
• 通常に戻ったら解決を発火。

ちらつくデータには「少なくとも N 分間 true」要件を追加できます — 閾値の周りで振動する IoT センサーでよくあります。

通知チャネル

Watch ごと、複数チャネル:

• メール — デフォルト。上書きしない限りアカウントメールへ。
• Slack — ドロップダウンからチャンネルを選択（ワークスペース管理者が Slack 統合を接続後）。
• Webhook — pagerduty、opsgenie、カスタム向け。
• SMS — Max プラン、Twilio 経由。
• アプリ内 — Tablize 受信トレイにバッジ付きで表示。

各チャネルは独自の重要度フィルタを持てます — 例: 「warning」をメールに、「critical」を Slack + SMS にルーティング。

クワイエットアワー

Watch は時間ウィンドウにスコープ可能:

• 常時 — デフォルト。
• オフィス時間 — 設定済み勤務時間。
• 深夜 — 例: 20:00〜07:00。
• カスタム — 任意の cron 式。

ウィンドウ外でもチェックは走りますがアラートは発火しません。あなたが戻ったとき条件がまだ true なら、「クワイエットアワー中に発火していました」サマリーを受け取ります。

確認とスヌーズ

アラート発火時:

• 確認 — 見たことを Tablize に伝える。条件が解決して再発火するまで同条件のさらなるアラートを抑制。
• N 時間スヌーズ — そのウィンドウ中チェックを完全に一時停止。
• 調査 — アラートをコンテキストにした新しいチャットセッションに連れていく。Agent が発火させたデータをプリロード。

未確認アラートはスケジュールでエスカレート（オプション）: 15 分後に再通知、その後毎時、その後停止。

Script との組み合わせ

Watch のクエリは Script にできます。複雑な多段チェックを構築する方法:

• Script が派生メトリクスを計算。
• Watch がメトリクスを閾値と比較。

メトリクスがテーブル間 JOIN、多段 Python、LLM ベースの分類（例: 「サポートチケットのセンチメントが X を下回ったら通知して」）を含むときに有用。

IoT Watch

Watch は IoT データで最も一般的なアセット。Agent は自然な言葉から Space / Asset / Point を理解:

> 冷蔵室 2 のいずれかの冷凍庫が深夜に −15°C を 5 分以上超えたらアラート。

Agent は:

1. 「冷蔵室 2 のいずれかの冷凍庫」を正しい Asset サブセットに解決。
2. temperature Point に対するチェックを書く。
3. 5 分デバウンスを追加。
4. クワイエットアワー（深夜 = 20:00〜07:00）を追加。
5. Slack で通知。

Asset グラフの詳細は IoT、MQTT、カメラ を参照。

Watch の確認

サイドバー → Watches が表示:

• すべての Watch、アクティブまたは一時停止。
• 最終発火時刻と現在の状態（ok / warning / critical / 一時停止）。
• 次のスケジュールチェック。
• 直近アラート履歴。

任意の Watch をクリックでクエリ、条件、直近発火を見て、何でも編集できます。

Watch vs Watch 履歴

2 つの異なるもの:

• Watch — ルール自体。サイドバーの Watches セクションに住む。
• Watch 履歴 — Watch が走るたびに見た値、発火したか。90 日保存。

Watch 履歴は SQL（platform.watch_runs）でクエリ可能 — 「先月このアラートは何回発火した？」メタ分析に有用。

よくある落とし穴

• 作成直後に Watch が常に発火。 閾値が通常のボラティリティに対してきつすぎる。デバウンスまたは相対デルタ条件を追加。
• 期待時に Watch が発火しない。 クエリが思った通りを返すか確認。Watch ページで Test run をクリック — クエリを実行して生値を表示。
• 通知が届かない。 通知設定を確認 — メールはスパムに行くことがある、Slack はアプリのインストールが必要。Watch ページがチャネルごとの配信ステータスを表示。
• Watch がデータベースを遅くする。 大きなテーブルに頻繁な Watch が多すぎるとアプリクエリと競合可能。より長い間隔を使うか、読み取りレプリカにルーティング。

次のステップ

• IoT、MQTT、カメラ — センサーデータは最も一般的な Watch ターゲット。
• Scripts — 多段ロジックを一度構築、出力で Watch。
• Dashboards — ページングではなくデータを見たいとき。