クローラーやAIエージェントが取得しようとしたときにダウンしているページは引用されず、壊れたページに着地した有料クリックはすべて無駄な支出になります。Audit → Uptime は、ドメインと主要ページを定期的にチェックし、失敗するとインシデントを作成して、知るべき人にアラートを送ります。SSL証明書、DNS、ドメインの有効期限、サイトの裏で動くジョブ、そして顧客が参照する公開ステータスページもカバーします。
稼働監視はStarterプラン以上で利用できます。モニター数はStarterが5、Proが20、Premiumが200、Enterpriseが無制限です。プランと上限 をご覧ください。
モニターを追加する# Uptimeを開いてAdd monitorをクリックする
Audit → Uptime → Monitors に移動し、Add monitor をクリックします。
タイプと対象を選ぶ
HTTP。 URLを指定します。空欄にするとホームページを監視します。期待するステータスコード（デフォルトは 2xx）を設定でき、任意で、ページに表示されなければならない、または表示されてはならないキーワード（「Fail when the keyword IS present」）も設定できます。TCP。 ホストとポートを指定します。DNS。 ホスト名、レコードタイプ、そして応答にすべて含まれていなければならない値を指定します。Transaction。 HTTPステップの連続です。各ステップには、独自のURL、最大応答時間、後続のステップで使うためにJSONやヘッダーから抽出する値を設定できます（例えば、ログインしてから、そのトークンでAPIを呼び出す）。間隔としきい値を設定する
チェック間隔を、1分ごと、5分、10分、30分ごと、または1時間ごとから選びます。1分と5分の間隔のチェックにはPro以上が必要で、Starterでは最短10分ごとです。ミリ秒単位の Degraded threshold と、90から99.999の間で任意の SLA target (%) を設定します。
アラートの送信先を選ぶ
Notification recipients は、モニターがダウンしたときと復旧したときにメールを受け取るワークスペースメンバーです（デフォルトはワークスペースのオーナー）。Slack または Webhook チャンネルを最大5件まで追加でき、Webhookには任意で署名シークレットを設定できます。Test でテスト通知を送信できます。Advanced settings では、リクエストメソッド、カスタムヘッダーと本文、劣化したチェックでのアラート、インシデントが継続している間の繰り返しアラートを設定できます。
インシデントの仕組み# Up、Degraded、Down。 劣化のしきい値より遅いチェックは Degraded となります。これは成功のままで、インシデントにはならず、オンにした場合のみアラートが送られます。2回の失敗でインシデントを作成。 1回の失敗したチェックは、何かが起こる前に確認されます。インシデントは2回連続で失敗した後にのみ作成されるため、一時的な不具合は除外されます。1回の成功で解決。 最初に成功したチェックで、失敗回数がリセットされ、インシデントが解決されます。各モニターのページには、15分単位のセルでの24時間の可用性、日別の90日間の可用性、チェックごとの応答時間とサイズ、詳細情報（レスポンスヘッダー、本文の抜粋、トランザクションのステップ）付きの最近のチェック、そしてインシデント一覧が表示されます。インシデント一覧では、インシデントの確認応答とコメントの追加ができます。Technical health パネルには、SSL証明書の有効性と有効期限までの日数、DNS解決、ドメイン登録の有効期限が加わります。
ハートビート# 稼働チェックは外部からサーバーを調べるため、夜間のバックアップやインポートが気づかないうちに止まっていても検出できません。ハートビート は方向を逆にします。ジョブが正常に実行されるたびに、固有のpingのURLを呼び出します。
crontab コピー
0 2 * * * /usr/local/bin/backup.sh && curl -fsS https://<your ping URL>Expected interval と、秒単位の Grace period を設定します。間隔に猶予を加えた時間内にpingが届かなければ、インシデントが作成されアラートが送られます。正確なpingのURLはハートビートのページからコピーしてください。Reset token で新しいURLが発行され、古いものは直ちに無効になります。ハートビートは、訪問者用のピクセル、ステータスバッジ、24時間または90日間の可用性チャートとしてWebページに埋め込むこともできます。
メンテナンスウィンドウ# 計画的な作業は障害としてカウントされるべきではありません。メンテナンスウィンドウ は、インシデントの変更を抑制し、その時間を稼働率の計算から除外します。ウィンドウは1回限り、毎日、毎週のいずれかで、1つのモニター、ドメイン、またはワークスペース全体を対象にできます。
ステータスページとSLAレポート# ステータスページ。 選択したモニターとハートビートについて、リアルタイムのインシデント状況を示す顧客向けページを公開します。訪問者は、可用性の更新情報をメールで購読できます。Published を切り替えると公開されます。SLAレポート。 メンテナンスを除いた、モニターとハートビートごとの月間稼働率を、各モニターのSLA目標と比較して示します。稼働時間、ダウンタイム、インシデント数、最長のインシデント、SLAを達成したかどうか、ダウンタイムの許容枠をどれだけ使用したか、または残っているかが分かります。顧客向けや社内報告用にCSVでダウンロードできます。具体例# 30日の月で99.9%の目標の場合、許容されるダウンタイムは 30 × 24 × 60 × 0.1% = 43.2 分です。12分と9分の2件のインシデントで21分を消費し、許容枠は約22分残ります。その月の60分のメンテナンスウィンドウは、これに含まれません。
ホームページだけでなくランディングページも監視する
広告や、最も引用されているコンテンツが指し示すページにもモニターを追加しましょう。稼働アラート、ハートビート、期限切れが近い証明書は受信トレイにも表示され、エージェントはMCPサーバー （uptime ツールセット）を通じてモニターを管理できます。
関連ページ# # 稼働監視
サイト、ページ、APIのダウンタイムや応答の遅延を監視し、ハートビートで定期ジョブを見守り、ステータスページを公開してSLAをレポートします。アラートはメール、Slack、Webhookで受け取れます。
クローラーやAIエージェントが取得しようとしたときにダウンしているページは引用されず、壊れたページに着地した有料クリックはすべて無駄な支出になります。**Audit → Uptime** は、ドメインと主要ページを定期的にチェックし、失敗するとインシデントを作成して、知るべき人にアラートを送ります。SSL証明書、DNS、ドメインの有効期限、サイトの裏で動くジョブ、そして顧客が参照する公開ステータスページもカバーします。
稼働監視はStarterプラン以上で利用できます。モニター数はStarterが5、Proが20、Premiumが200、Enterpriseが無制限です。[プランと上限](/docs/account/plans-and-limits/)をご覧ください。
## モニターを追加する
**Audit → Uptime → Monitors** に移動し、**Add monitor** をクリックします。
- **HTTP。** URLを指定します。空欄にするとホームページを監視します。期待するステータスコード（デフォルトは `2xx`）を設定でき、任意で、ページに表示されなければならない、または表示されてはならないキーワード（「Fail when the keyword IS present」）も設定できます。
- **TCP。** ホストとポートを指定します。
- **DNS。** ホスト名、レコードタイプ、そして応答にすべて含まれていなければならない値を指定します。
- **Transaction。** HTTPステップの連続です。各ステップには、独自のURL、最大応答時間、後続のステップで使うためにJSONやヘッダーから抽出する値を設定できます（例えば、ログインしてから、そのトークンでAPIを呼び出す）。
チェック間隔を、1分ごと、5分、10分、30分ごと、または1時間ごとから選びます。1分と5分の間隔のチェックにはPro以上が必要で、Starterでは最短10分ごとです。ミリ秒単位の **Degraded threshold** と、90から99.999の間で任意の **SLA target (%)** を設定します。
**Notification recipients** は、モニターがダウンしたときと復旧したときにメールを受け取るワークスペースメンバーです（デフォルトはワークスペースのオーナー）。**Slack** または **Webhook** チャンネルを最大5件まで追加でき、Webhookには任意で署名シークレットを設定できます。**Test** でテスト通知を送信できます。**Advanced settings** では、リクエストメソッド、カスタムヘッダーと本文、劣化したチェックでのアラート、インシデントが継続している間の繰り返しアラートを設定できます。
## インシデントの仕組み
- **Up、Degraded、Down。** 劣化のしきい値より遅いチェックは **Degraded** となります。これは成功のままで、インシデントにはならず、オンにした場合のみアラートが送られます。
- **2回の失敗でインシデントを作成。** 1回の失敗したチェックは、何かが起こる前に確認されます。インシデントは2回連続で失敗した後にのみ作成されるため、一時的な不具合は除外されます。
- **1回の成功で解決。** 最初に成功したチェックで、失敗回数がリセットされ、インシデントが解決されます。
各モニターのページには、15分単位のセルでの24時間の可用性、日別の90日間の可用性、チェックごとの応答時間とサイズ、詳細情報（レスポンスヘッダー、本文の抜粋、トランザクションのステップ）付きの最近のチェック、そしてインシデント一覧が表示されます。インシデント一覧では、インシデントの確認応答とコメントの追加ができます。**Technical health** パネルには、SSL証明書の有効性と有効期限までの日数、DNS解決、ドメイン登録の有効期限が加わります。
## ハートビート
稼働チェックは外部からサーバーを調べるため、夜間のバックアップやインポートが気づかないうちに止まっていても検出できません。**ハートビート**は方向を逆にします。ジョブが正常に実行されるたびに、固有のpingのURLを呼び出します。
```bash {title="crontab"}
0 2 * * * /usr/local/bin/backup.sh && curl -fsS https://<your ping URL>
```
**Expected interval** と、秒単位の **Grace period** を設定します。間隔に猶予を加えた時間内にpingが届かなければ、インシデントが作成されアラートが送られます。正確なpingのURLはハートビートのページからコピーしてください。**Reset token** で新しいURLが発行され、古いものは直ちに無効になります。ハートビートは、訪問者用のピクセル、ステータスバッジ、24時間または90日間の可用性チャートとしてWebページに埋め込むこともできます。
## メンテナンスウィンドウ
計画的な作業は障害としてカウントされるべきではありません。**メンテナンスウィンドウ**は、インシデントの変更を抑制し、その時間を稼働率の計算から除外します。ウィンドウは1回限り、毎日、毎週のいずれかで、1つのモニター、ドメイン、またはワークスペース全体を対象にできます。
## ステータスページとSLAレポート
- **ステータスページ。** 選択したモニターとハートビートについて、リアルタイムのインシデント状況を示す顧客向けページを公開します。訪問者は、可用性の更新情報をメールで購読できます。**Published** を切り替えると公開されます。
- **SLAレポート。** メンテナンスを除いた、モニターとハートビートごとの月間稼働率を、各モニターのSLA目標と比較して示します。稼働時間、ダウンタイム、インシデント数、最長のインシデント、SLAを達成したかどうか、ダウンタイムの許容枠をどれだけ使用したか、または残っているかが分かります。顧客向けや社内報告用にCSVでダウンロードできます。
### 具体例
30日の月で99.9%の目標の場合、許容されるダウンタイムは `30 × 24 × 60 × 0.1% = 43.2` 分です。12分と9分の2件のインシデントで21分を消費し、許容枠は約22分残ります。その月の60分のメンテナンスウィンドウは、これに含まれません。
広告や、最も引用されているコンテンツが指し示すページにもモニターを追加しましょう。稼働アラート、ハートビート、期限切れが近い証明書は受信トレイにも表示され、エージェントは[MCPサーバー](/docs/mcp/toolsets/)（`uptime` ツールセット）を通じてモニターを管理できます。
## 関連ページ
クローラーのアクセスと証明書の有効期限を1か所で確認できます。プランごとのモニター数とチェック間隔です。ダウンタイムによる有料クリックの損失額を把握します。エージェントにモニターとステータスページを管理させます。
Source: https://www.amicited.com/ja/docs/improve/uptime/ 
