uptimelens/claude-plugins

UptimeLens 監視

UptimeLens MCPサーバーを通じて、顧客自身のリソース上でUptimeLensアップタイム監視をセットアップし実行します。このスキルは、監視リクエスト（「このURLを監視して」「このデプロイ後に何を監視すべき？」「何がダウンしている？」「インシデントをオープンして」）を、正しいMCPツール呼び出しのシーケンスに変換します。

このスキルを使用するタイミング

製品の監視設定とインシデント記録管理の側面で使用します。

• HTTP/HTTPSモニターを作成し、デプロイ後や新しいサービスのための監視範囲を推奨します。
• 現在ダウンしているものを確認し、軽度の調査（ステータス履歴、プローブ別根本原因、応答時間/可用性）を行います。
• メンテナンスウィンドウをスケジュールして、デプロイや計画作業によるページングを防ぎます。
• モニター依存関係をモデル化し、上流がすでにダウンしている場合に下流のチェックがアラートを発しないようにします。
• インシデントのオープン、更新、解決を行います。

リクエストが監視ではなく、ページへの対応に関するものである場合（アクティブなエスカレーションの確認やスヌーズ、シフトカバー、エスカレーション実行の調査など）は、uptimelens-on-call スキルを使用してください。インシデントの詳細なガイド付き根本原因調査には、ここで分析全体をスクリプト化するよりも、読み取り専用の triage_incident MCPプロンプト（および get_root_cause ツール）を優先してください。

前提条件

1. UptimeLens MCPサーバーがこのクライアントに接続されていること。読み取りツールはすべてのプランで動作します。
2. 書き込みアクション（create_monitor、update_monitor、pause_monitor、resume_monitor、register_monitor_dependency、delete_monitor_dependency、create_incident、post_incident_update、resolve_incident、cancel_incident、reopen_incident、save_postmortem、add_incident_action_item、create_maintenance、delete_maintenance）には、読み書き可能なAPIトークンとProプラン以上が必要です。読み取り専用トークンの場合、書き込みツールはリストにすら表示されません。Freeプランでは FeatureNotAvailable が返されます。
3. 一部の読み取りツールはプランによって制限されています。get_root_cause（有料）と get_incident_analytics（Pro+）はハードゲートされています。これらのプラン未満では FeatureNotAvailable エラーが返されるため、書き込みツールの前提条件と同様に処理し（プランが満たされていないことをユーザーに伝え、再試行しないでください）、query_metrics パーセンタイルはソフトゲートされています。Team未満のプランではパーセンタイルフィールドがnullで返され、エラーにはなりません。

書き込みツールが見つからないか FeatureNotAvailable を返す場合は、再試行する代わりに、どの前提条件が満たされていないかをユーザーに伝えてください。

ツール

これらのツールはUptimeLens MCPサーバーから提供されます。完全修飾名 UptimeLens:<tool> で参照してください。UptimeLens の部分は、このクライアントでコネクタに付けられた名前に置き換えてください。そうしないとツールが見つからない可能性があります。

読み取り（発見とコンテキスト）:

• UptimeLens:get_overview — 「今何が壊れている？」という質問の出発点：ステータス別のモニター数、24時間のアップタイム、オープン中のインシデント、およびグループ化された個別の障害。同じ方法で同じターゲットで壊れた40のモニターが、40行ではなく1つの停止として表示されます。名前、タグ、IDなどのインベントリ自体が必要な場合は、代わりに list_monitors を使用してください。
• UptimeLens:list_monitors — 現在のヘルス情報を持つモニターのリスト。status（up/degraded/down/unconfirmed-down/unknown/not-monitored/in-maintenance）、名前、またはタグでフィルタリングできます。ほとんどすべての操作の monitorId のソースであり、「何がダウンしている？」という質問の答えです。
• UptimeLens:get_monitor — 1つのモニターの設定と現在のヘルス情報（認証情報は含まれません）。
• UptimeLens:list_status_changes — 1つのモニターのアップ/ダウン/デグレードの履歴とその期間。get_root_cause が必要とする statusChangeId のソースです。
• UptimeLens:get_status_change — 1つのステータス変更とそのコンテキスト（前後の変更、それをカバーするインシデントとエスカレーション実行）、およびその前後のチェックに関するロケーション別の概要（失敗した数、firstDownAt、最も頻繁な errorCategory）を提供します。停止がどこから始まり、どのように確認されたかを伝えるために使用します。すべてのプランで利用可能です。
• UptimeLens:get_root_cause — 1つのステータス変更に対するプローブ別のネットワーク診断：DNS/接続/TLSタイミング、traceroute、TLSバージョン、SSL残り日数、エラーカテゴリ。「なぜダウンしたのか」の最も豊富な情報源です（有料プラン）。
• UptimeLens:query_metrics — 一定期間における1つのモニターの応答時間とアップタイム統計（期間サマリー、完全な系列ではありません。パーセンタイルはTeam+）。
• UptimeLens:get_monitor_availability — 1つのモニターのSLAビュー：アップタイム%、ダウンタイム、インシデント数、MTTR、MTBF、応答時間統計。読み取り時の注意：uptimePct がない場合は、その期間に測定値がなかったことを意味します（100%ではありません。モニターが測定されなかったと伝えてください）。longestIncidentSec はインシデントの経過時間であり、測定された totalDowntimeSec を超える可能性があります（これは期待される動作であり、データエラーではありません）。uptimePct は小数点第2位に丸められるため、非常に短い停止でもダウンタイムが正の値となり100.00と表示されることがあります。mtbfSec/mttrSec がない場合は、ゼロではありません。
• UptimeLens:get_uptime_report — アカウント全体の同じ質問に対する一定期間の回答：時間加重アップタイム、ダウンタイム、SLA目標に対するエラーバジェット、および何が壊れたか（causes）とどこから確認されたか（locations）。プリセット（last_month、last_30d、…）または明示的な日付で期間を選択します。「先月はどうだった？」に使用します。単一モニターの場合は get_monitor_availability を使用します。
• UptimeLens:list_monitor_dependencies — モニターが依存する親モニターのリスト（アラートを発火させるためにアップしている必要があるもの）。
• UptimeLens:list_monitor_dependents — 逆方向：このモニターに依存するモニターのリスト。つまり、そのブラスト半径であり、根本原因と症状を区別するために使用します。
• UptimeLens:list_incidents — インシデントのリスト（新しい順）。startDate/endDate を渡さない限り、デフォルトで過去7日間が対象です。status、monitorId、または source でフィルタリングできます。
• UptimeLens:get_incident — 1つのインシデントの詳細とその更新タイムライン、影響を受けたモニターを表示します。
• UptimeLens:get_incident_analytics — 日付範囲におけるフリートレベルのインシデントメトリクス（MTTR、量/トレンド、重大度/ソース別内訳、トップモニター）— Pro+。
• UptimeLens:list_maintenance — メンテナンスウィンドウのリスト。status=active は「現在メンテナンス中のものはあるか？」という質問に答えます。
• UptimeLens:list_status_pages / UptimeLens:get_status_page — 顧客に公開されているものと、どのモニターがページに表示されているか（カバレッジを決定する際に役立ちます）。

書き込み（状態変更 — 「書き込み前に確認」を参照）:

• UptimeLens:create_monitor — URLからHTTP/HTTPSモニターを作成します。「create_monitorでできることとできないこと」を参照してください。
• UptimeLens:update_monitor — 既存のモニターの名前やチェック間隔を編集します（id + name および/または intervalSeconds、少なくとも1つ）。他のすべての設定（URL、タイプ、認証、ヘッダー、しきい値、リージョン）はそのまま保持され、MCP経由では変更できません。可逆的で冪等です。
• UptimeLens:pause_monitor / UptimeLens:resume_monitor — 1つのモニターのアクティブな監視を停止または再開します。入力：id。可逆的で冪等です。
• UptimeLens:register_monitor_dependency — 子→親の依存関係を宣言します。親がダウンしている間、子のダウンアラートは抑制されます。入力：monitorId（子）、parentId。直接の親のみ。循環/自己は拒否されます。
• UptimeLens:delete_monitor_dependency — レコード id（list_monitor_dependencies から）によって依存関係エッジを削除します。モニターは削除されません。
• UptimeLens:create_incident — インシデントをオープンします。「インシデントはドラフトとしてオープンされる」を参照してください。
• UptimeLens:post_incident_update — メッセージ付きのタイムライン更新（investigating/identified/monitoring）を追加します。notifySubscribers=true を渡さない限り、購読者にはメールは送信されません（インシデントがすでに公開されている場合のみ）。
• UptimeLens:resolve_incident — インシデントを解決済みとしてマークします。notifySubscribers=true を渡さない限り、購読者にはメールは送信されません（公開されている場合のみ）。reopen_incident で元に戻せます。
• UptimeLens:cancel_incident — false_alarm/duplicate/test としてキャンセルします。終端（再オープン不可）、分析から除外されます。デフォルトではサイレントです。
• UptimeLens:reopen_incident — 以前に解決されたインシデントを再オープンします（キャンセルされたインシデントは再オープンできません）。
• UptimeLens:save_postmortem — インシデントの事後分析本文をマークダウンとして書き込み（または上書き）します。オプションで status を draft または in_review に設定できます。postmortem_draft プロンプトの出力はここに格納されます。これがないと、ドラフトはチャット内にのみ存在します。公開はダッシュボードでの人間の手順として残ります。
• UptimeLens:add_incident_action_item — インシデントにフォローアップアクションアイテムを追加します（タイトル、およびオプションでタイプ、優先度、期限）。事後分析のうち、実際に何かを変える半分です。
• UptimeLens:create_maintenance / UptimeLens:delete_maintenance — メンテナンスウィンドウをスケジュールまたはキャンセルします。ウィンドウ中は、そのモニターのアラートが抑制されます。

コアワークフロー：監視のセットアップ（特にデプロイ後）

まずは発見から。ほとんどの書き込みにはID、または現在のインベントリだけが提供できる情報に基づく決定が必要です。以下のチェックリストをコピーして進めてください。

監視のセットアップ:
- [ ] 1. 現在のカバレッジを確認する（list_monitors）— 何が存在するか、何が不足しているか、何がすでにダウンしているか
- [ ] 2. 新しいURL/サービスの場合：重複がないか list_monitors を確認する（create_monitor は冪等ではありません）
- [ ] 3. URLをユーザーと確認し、create_monitor を実行する（HTTP/HTTPSのみ）
- [ ] 4. 必要に応じてトポロジを配線する（register_monitor_dependency：新しいチェックをその上流の下に配置）
- [ ] 5. デプロイ/メンテナンスが行われる場合は、ノイズを抑制する（ウィンドウに対して create_maintenance）

ステップ1 — インベントリ。 list_monitors を呼び出します。「何がダウンしている？」に答えるには、status=["down"] を渡します（ユーザーが「不健全」を意味する場合は、degraded/unconfirmed-down を追加します）。これは、ユーザーがデプロイしたばかりで一致するモニターがないサービスなど、ギャップを見つける方法でもあります。

ステップ2-3 — 注意して作成。 create_monitor は冪等ではありません。同じURLに対して2回呼び出すと、2つのモニターが作成されます。最初に list_monitors で既存のモニターを確認し、作成前にユーザーと正確なURLを確認してください。以下の制約を参照してください。

ステップ4 — トポロジ（オプション）。 新しいモニターが既に監視しているものの下流にある場合（ゲートウェイの背後にあるアプリ、データベースの背後にあるサービスなど）、新しいモニターを monitorId、上流を parentId として register_monitor_dependency を使用して依存関係を登録し、上流が本当の問題である場合に子がページングしないようにします。

ステップ5 — デプロイノイズの抑制（オプション）。 ユーザーがデプロイまたは計画作業を行っている場合は、影響を受けるモニターに対してウィンドウを指定して create_maintenance を実行し、作業自体によってページングが発生しないようにします。

create_monitorでできることとできないこと

create_monitor はクイック追加機能です。URLを指定すると、HTTP/HTTPSモニターが作成され（スキームが指定されていない場合はhttpsが想定されます）、モニター名はデフォルトでホスト名になり、チェック間隔とアラートグループはテナントのデフォルトを使用します。

MCP経由ではできません：非HTTPモニター（TCP/UDP、DNS、ping/ICMP、SSH、SMTPなど）の作成、または認証、カスタムヘッダー、キーワード/本文アサーション、特定の間隔、アラートグループの設定。これらのいずれかが必要な場合は、ダッシュボードで設定を完了するようにユーザーに伝えてください。MCPで設定できるふりをしないでください。作成後、update_monitor はモニターの名前とチェック間隔のみを変更できます（その2つだけ。その他はすべてダッシュボードに任せます）。モニターを削除するための delete_monitor ツールはありません。モニターを削除するには、ユーザーをダッシュボードに誘導してください。

インシデントはドラフトとしてオープンされる

create_incident は常に未公開のドラフトをオープンします。ステータスページには表示されず、購読者にも通知されません。公開は人間がダッシュボードから行います。インシデントを作成する際は、まだ公開されていないことをユーザーが認識できるように、このことを伝えてください。post_incident_update、resolve_incident、cancel_incident、reopen_incident は、明示的に notifySubscribers=true を渡した場合にのみ購読者にメールを送信します。MCPのデフォルトはサイレントです。これは、顧客自身の顧客へのメールは取り消せないためです（ダッシュボードでは動作が逆で、人間がボタンを押します）。cancel_incident は終端（false_alarm/duplicate/test）であり、再オープンできません。resolve_incident は reopen_incident で元に戻せます。「これは本物ではなかった」場合は cancel、「これは終わった」場合は resolve を使用してください。

書き込み前に確認

読み取りと推奨は自由に行ってください。書き込みを行う前には、これから何をしようとしているかを伝え、ユーザーの了解を得てください。これらの操作は、何が監視されるか、何がページングされるか、何が記録されるかを変更します。

• モニター作成：正確なURLを伝えます。冪等ではないため、既にそのモニターがないことを確認してください（list_monitors で確認済み）。
• 一時停止/再開：一時停止は監視を停止するため、一時停止中は実際の停止がページングされません。ユーザーがそれを抑制するつもりであることを確認してください。
• メンテナンス：モニターと正確なウィンドウ（RFC3339。デフォルトはUTC、または Europe/Istanbul などのIANA timezone を渡すこともできます。繰り返しウィンドウはDST対応です）を伝えます。期間中、アラートは抑制されます。
• インシデントのオープン/更新/解決/キャンセル：インシデントを伝え、解決/キャンセルの場合は、購読者へのメール送信を求めているかどうか（notifySubscribers=true）を伝えます。デフォルトではメールは送信されません。

最も驚きの少ないアクションを優先し、大規模に作成するのではなく推奨し、インシデントごとの確認なしに一括でインシデントをオープンまたは解決しないでください。

一般的なシナリオ

「https://api.example.com を監視してください。」 list_monitors（既に監視されていないか確認）→ URLを確認 → create_monitor(url)。ユーザーが認証、キーワードチェック、または非HTTPプロトコルを希望する場合は、基本的なHTTPモニターを作成し、それらの設定はダッシュボードで完了するように伝えてください。

「billingサービスをデプロイしたばかりですが、何を監視すべきですか？」 list_monitors で現在のカバレッジを確認 → ギャップを特定（モニターがない新しいパブリックエンドポイント/ヘルスチェック）し、サイレントに作成するのではなくユーザーに推奨 → 確認後、それぞれに対して create_monitor → 新しいモニターが既に監視しているものの背後にある場合は、register_monitor_dependency でその上流の下に配置します。自動生成できないもの（非HTTP、認証、キーワード）を指摘し、ダッシュボードに任せてください。

「今何がダウンしていますか？」 最初に get_overview を呼び出します。これは…（後略）