サイトの稼働時間と停止時間を監視する

Jetpackの停止時間モニターは、ウェブサイトを継続的に監視し、停止を検知した瞬間に通知します。

Jetpackのダウンタイム監視を有効にすると、いずれかのサーバーが5分ごとにサイトをチェックし始めます。問題が発生したように見える場合は、アラート通知に登録したサイト管理者にメールでお知らせします（詳しくはメールをご覧ください）。詳しい情報とよくある質問については、機能ページをご覧ください。

要件MD

Jetpackの停止時間監視には、動作しているJetpack接続が必要です。この機能を有効にするには、Jetpackプラグインをインストールして有効化する必要があります。

Jetpackの停止時間監視は無料の機能であり、Jetpackのプランは必要ありません。

停止時間監視を有効または無効にするMD

あなた、またはJetpackに接続している他の管理者は、WP Adminから停止時間監視を有効または無効にできます。

1. WordPress管理画面でJetpack → 保護に移動し、設定タブをクリックします。
2. 設定のダウンタイム監視カードで、「ダウンタイム監視を有効にする」を有効にすると、サイトがオフラインになったときに通知を受け取れます。無効にすると、サイトのチェックと通知が停止します。
3. 「サイトが停止・復旧したときにメールで通知する」。

監視を有効にしたまま自分へのメールだけを停止するには、同じカードで「サイトが停止・復旧したときにメールで通知する」を無効にします。この設定には、WordPress.comアカウントを接続する必要があります。接続されていない場合は、先に接続するようページで求められます。

Protectページの概要タブにあるダウンタイム監視カードには、過去40日間のサイトの稼働状況が日ごとに表示されます。日付にカーソルを合わせると、サイトが稼働していたか、停止していた時間の長さを確認できます。WordPress.comアカウントがまだ接続されていない場合、このカードから接続して稼働履歴を確認するよう求められます。

スタンドアロン版のJetpack Protectプラグインが有効になっている場合、JetpackメニューにはこのProtectページが表示されず、サイトでは以前の画面が引き続き使用されます。この設定はJetpack → 設定 → セキュリティにあります。Jetpackバージョン16.4未満のサイトでも、この場所を使用します。

メールMD

停止通知はユーザーごとに送信されます。WordPress.comアカウントをJetpackに接続している各管理者は、Protectページの「サイトが停止・復旧したときにメールで通知する」切り替えで自分で設定します。有効にすると自分のWordPress.comアカウントが登録され、無効にすると登録が解除されます。停止時間監視を有効にしたユーザーは、WordPress.comアカウントが接続されていれば自動的に登録されます。通知は各アカウントのWordPress.comメールアドレスに送信されます。現在、これらのメールに他の受信者を追加したり、CCに含めたりすることはできません。

Jetpack 16.4以降、ダウンタイム監視カードは、設定タブのJetpack → 保護にあり、アラートの送信先アドレスを示します。例えば、「メールの送信先はyou@example.com、あなたのWordPress.comアカウントのアドレスです。」

通知に使用される日時は、WordPressの設定（設定 > 一般）で設定されているタイムゾーンに基づきます。

これらの通知メールが迷惑メールに振り分けられないようメールフィルターに設定を追加する場合、送信元はsupport+monitor（アット）jetpack（ドット）comです。

もう管理していないサイトの停止通知が届き続ける場合は、サポートにお問い合わせください。

停止ステータスの通知MD

Jetpackモニターは、サイトが停止していることを記録すると、その理由もステータスとして記録します。このステータスは、サイトが停止している理由を説明するのに役立ちます。停止通知メールでこのステータスを確認できます。

ステータスは、停止通知メールの下部にある参照番号に含まれています。この参照番号は次のようになります：[23454191/server]。番号はサイトの内部IDです。2番目の部分は返されたステータスです。

Jetpackの停止通知では、次のステータスが返されます。これらのステータスを使用して、サイトが停止している理由を確認できます。

• 「server」 — 5xxレスポンス。サーバーで何らかの致命的なエラーが発生したことを意味します。特に、テーマやプラグインの1つが致命的なエラーを発生させている場合です。
• 「blocked」 — 403レスポンス。サーバーがホームページの閲覧を禁止したことを意味します。
• 「client」 — 403以外の4xxレスポンス。同様に、サーバー側の設定によってアクセスが無効にされている可能性があります。
• 「intermittent」 — 10秒経過しても応答がなく、リクエストがタイムアウトしました。このケースは、サイトが実際には読み込み中でも、非常に遅いだけの場合があるため、判断が難しいことがあります。共有ホストでサーバー上の別のサイトがリソースを使いすぎると、同じサーバー上の他のサイトの応答も遅くなる可能性があるため、これは自然に解消する可能性が最も高いケースでもあります。サイトを停止と判定するには、メインの監視サーバーと複数の確認サーバーがすべてこの状態を検出する必要があります。
• 「redirection」 — 3xxレスポンス。モニターは複数のリダイレクトを追跡しますが、4回目のリダイレクトを追跡するよう求められた場合は、問題があると判断します。実際にはリダイレクトループを示している可能性がありますが、比較的適切でない設定の場合もあります（例：yourjetpack.blog -> http://www.yourjetpack.blog -> http://www.yourjetpack.blog/en/ -> http://www.yourjetpack.blog/en/blog/なら停止と判定されます）。
• 「success」 — 正常なレスポンスです。すべて正常に動作しました。これは、フォローアップの「サイトが復旧しました！」というメールでのみ表示されます。
• 「unknown」 — 通常は発生しないはずです。監視サービスがWordPress.comに対して期待された応答を送信できなかったことを示します。

これらは、サイトのホームページへのHTTP HEADリクエストに対するHTTPレスポンスコードに基づいており、サイトが停止している理由の確認に役立ちます。

停止通知を受け取ったが、サイトはオフラインになっていないMD

Jetpack停止時間モニターは、サイトが正常に動作しているように見える場合でも、通知を送ることがあります。誤検知の最も一般的な理由は次のとおりです。

• サイトの応答が断続的、または遅すぎます。
  サイトの読み込みに20秒を超える時間がかかる場合、アクセス不能と判断して通知を送信します。これは、サーバーリソースが限られており、他のサイトと共有されている共有ホスティングでよく発生します。読み込むリソースが多い重いホームページも、読み込みを遅くすることがあります。
  アラートが1回だけ届き、サイトがすぐに正常に戻った場合は、一時的な問題で、すでに自然に解消した可能性が高いです。
• リダイレクトが多すぎます。
  監視エージェントが過剰なリダイレクトを検出すると、ダウンタイムアラートが発生することがあります。サイトのURLが正しく設定されていることを再確認し、設定に誤りがある可能性のあるリダイレクトプラグインを確認してください。
• Jetpackがブロックされています。
  ホスティングプロバイダーによっては、Jetpackの監視エージェントをブロックする場合があります。ホストが次のユーザーエージェントからのリクエストを許可していることを確認してください。
  jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)

不明な点がある場合、または問題が解決しない場合は、サポートにお問い合わせください。

監視のテストMD

Jetpackの監視エージェントがブロックされているかどうかを確認するには、ターミナルで次のコマンドを実行できます。サイトが稼働している場合は、200が返されます：

curl -IA "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)" https://yourjetpack.blog

次の文字列yourjetpack.blogをサイトのドメインに置き換える必要があります。

この仕組みの舞台裏を教えてください。MD

Jetpackがサイトを確認すると、HTTP HEADリクエストを使用して5分ごとにサイトのホームページへpingを送信します。

HTTPレスポンスコードが400以上の場合、権限エラーまたは致命的なコードエラーによってサイトが訪問者に表示されていない可能性があるため、サイトが停止していると暫定的に判断します。また、リダイレクトループを示す300番台のリダイレクトが3回を超えた場合や、サイトが20秒以内に応答しない場合も同様です。

サイトが停止していると暫定的に判断すると、問題が当社のネットワークや主要データセンターの所在地に限定されたものではないことを確認するため、地理的に異なる場所にあるサードパーティーベンダーの3台の別々のサーバーを起動して確認します。3台すべての確認に失敗した場合、サイトが停止していると判断し、お知らせします。

Jetpack Monitorがサイトで動作しているかどうかは、以下のcURL（クライアントURL）コマンドを実行し、「yourjetpack.blog」をご自身のサイトのURLに置き換えることでテストできます：

curl -IA "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)" https://yourjetpack.blog

レスポンスが200 OKであれば、正常に動作しています。

既知の問題MD

ダウンタイム通知の見逃しとCloudflare

Cloudflareを使用していてサイトが停止している場合、ダウンタイム監視で検知できないことがあります。これはCloudflareの仕組みによるものです。オリジンサーバー（ウェブホスト）が停止すると、Cloudflareによってサイトのキャッシュコピーが提供されます。そのため、ダウンタイム監視はキャッシュコピーを確認し、オリジンサーバーの停止を検知できません。

Cloudflareの「Under Attack」モードによって誤ったオフラインアラートが発生するMD

Cloudflareの「Under Attack」モードが有効になっていると、Jetpack Monitorの確認で、サイトの通常のレスポンスではなくCloudflareのブラウザチャレンジページを受信することがあります。MonitorはJavaScript/ブラウザーベースのチャレンジを完了できないため、オリジンサイトが正常な場合でも確認が失敗したとみなされることがあります。

詳しくは監視のテストのcurlコマンドを実行して、Jetpack Monitorエージェントがブロックされているか確認してください。

200 OKの応答は、Monitorが正常にサイトへアクセスできることを示します。4xx、5xx、タイムアウト、またはCloudflareチャレンジの応答が返された場合は、Monitorがブロックまたはチャレンジされている可能性があります。リダイレクトは追従されますが、過剰なリダイレクトによってアラートが発生する場合があります。

回避策

1. Monitorエージェント用にCloudflare WAFのバイパスルールを作成する（推奨）
   • 次の場所に移動します：Cloudflareダッシュボード → セキュリティ → WAF → カスタムルール
   • ルールを作成します：ユーザーエージェントに次を含む jetmon/1.0 → スキップ（チャレンジをバイパス）
   • これにより、他のすべてのトラフィックでは「Under Attack」モードを有効にしたまま、Monitorを通過させることができます。
2. より対象を絞ったCloudflareの保護を使用する
   • レート制限、Bot Fight Mode、または特定の脅威を対象とするWAFカスタムルールは、完全な「Under Attack」モードよりも稼働時間の確認を妨げる可能性が低くなります。
3. 一時的にトレードオフを受け入れる
   • 「Under Attack」モードを攻撃が発生している期間だけ使用する場合、誤ったアラートが発生するのは想定内であり、モードを無効にすると停止します。

オフラインまたは稼働していないサイトでもMonitorアラートが届く

閉鎖され、すでに存在しないサイトについて、Jetpack Monitorからダウンタイム通知が届くことがあります。これは、Jetpack Monitorがサイトの状態を確認し続けるためです。Jetpack接続を停止しない限り、確認は継続されます。

不要な通知が届いていて、サイトのWP Adminエリアにアクセスできなくなっている場合は、Jetpackサポートに直接お問い合わせください。

プライバシー情報MD

ダウンタイム監視はデフォルトでは無効化されています。WP管理画面のJetpack → 保護 → 設定で有効にできます。『ダウンタイム監視』カードで有効にできます。またはお使いのWordPress.comダッシュボードの設定→セキュリティから有効にできます。