稼働率99.9%でも、クライアントサイトが正常に動いているとは限らない

「稼働率99.9%」のクライアントサイトと聞くと安心に思えます。しかしこの数字でも、年間8.76時間、30日の月なら約43分のダウンタイムが許容されます。しかも数えているのは、サーバーがまったく応答しなかった時間だけです。

より大きな問題は、稼働チェックが何をもって「稼働中」とするかです。サイトはすべてのチェックに応答していても、訪問者にとっては壊れていることがあります。

稼働チェックが実際に確認していること

基本的なHTTPチェックが問うのは1つだけです。サーバーが成功を意味するステータスコードで応答するかどうか、という点です。見ているのはステータスコードだけで、ページの中身は読みません。

そのため、成功ステータスで応答しさえすれば、次のどれも「稼働中」と判定されます。

• キャッシュ、テーマ、ページビルダーの不具合による真っ白なページ
• ホスティング会社の「アカウント停止」や「制限超過」のページ
• ドメイン登録が失効した後のレジストラのページ（.comのような汎用ドメインが期限切れになると、レジストラはそのドメインがあなたのサイトに名前解決されないようにしなければならず、代わりに更新案内のページを表示することがあります）
• チェックがリダイレクトを追わない場合の、それ自体が壊れているページへのリダイレクト
• 読み込まれはするものの、送信すると失敗するお問い合わせフォームやチェックアウト

チェックとチェックの間の空白もあります。5分ごとのチェックでは、3分間の障害が2回のチェックの間に始まって終わり、稼働率の数字に一度も表れないことがあります。

ステータスコードだけでなくコンテンツを確認する

キーワードチェックはページをダウンロードし、特定のテキストを探します。使い方は2通りあります。

• テキストがないときに失敗させる：ページが本当に機能しているときにだけ存在するテキストを選びます。空のレスポンス、停止のお知らせ、レジストラのページにはそのテキストは含まれません。
• テキストが現れたときに失敗させる：何かがおかしいときにだけ表示されるテキストを選びます。たとえば「Fatal error」や「Database error」です。

テキスト選びが作業の大部分です。

• サーバーがHTMLで送るテキストを使います。キーワードチェックが読むのはページのソースで、ページの読み込み後にJavaScriptが追加する内容ではありません。
• CMSがコンテンツから出力するテキスト、たとえばセクションの見出しやフッターの電話番号を使います。サイト名のように、静的なエラーテンプレートにも含まれていそうなテキストは避けます。
• 価格、日付、最新記事のタイトルなど、変わるテキストは避けます。
• 最終的なURLをチェックします。example.comがhttps://www.example.com/にリダイレクトする場合は、後者を監視します。

トップページに1つ、クライアントの収益につながるページ（予約ページ、ショップのカテゴリーページ、お問い合わせページ）に1つキーワードチェックを置けば、訪問者が気づく問題の大部分をカバーできます。

遅いことはダウンではない

稼働チェックは、タイムアウトを記録するまでサーバーに数秒の猶予を与えます。表示までに8秒かかるページは「ダウン」ではありませんが、訪問者にとってはダウンしているのとほとんど変わりません。

遅さは2つの場所に表れます。

• 各チェックの応答時間：ホスティングの変更やプラグインの更新の後に上昇傾向が見られたら、それが最初の兆候です。これはサーバーが応答する速さを測るもので、ページの描画にかかる時間ではありません。
• ページ速度テスト：Google PageSpeed Insightsの基盤でもあるLighthouseは、ブラウザでページがどう読み込まれるかを測定します。稼働チェックではこれは測れません。

クライアントから苦情が来たときだけでなく、更新のたびに両方を確認してください。

「ダウン」が実はダウンではないとき

逆のことも起こります。一部のサイトはボット対策の背後にあり、データセンターにある監視サービスには、訪問者のブラウザとは異なる応答を返すことがあります。すると監視サービスはサイトをダウンと報告しますが、ほかの人には問題なく開けます。

私たちも2026年9月上旬にこれに遭遇しました。ある大規模な公開サイトのモニターが長時間のインシデントの間ずっとダウンのままでしたが、ブラウザではページが普通に読み込まれ、ほかのリージョンからのチェックはすべて稼働中と報告していました。障害についてクライアントに連絡する前に、通常の回線から自分でサイトを開いてみてください。

どの稼働チェックでもカバーできないこと

稼働チェックとキーワードチェックが読み込むのは1つのURLです。ログインも、フォームへの入力も、カートへの商品追加も、支払いもしません。Baromioもスクリプトによる複数ステップのシナリオは実行しません。

こうした流れに収益が左右されるクライアントの場合は、プラグイン、テーマ、決済まわりを更新するたびに手動でテストしてください。お問い合わせフォームを自分宛てに送信する、テスト注文をする、テストアカウントでログインする、といった作業です。数分で終わり、URLチェックでは捉えられない問題を見つけられます。

Baromioでの設定方法

• HTTPモニター：HEADリクエストを送信し（サーバーがHEADを拒否した場合はGET）、400未満のステータスをすべて稼働中とみなし、リダイレクトは追いません。答えるのは「サーバーは応答しているか」という問いです。
• キーワードモニター：GETでページを取得し、大文字と小文字を区別せずにHTMLソースからあなたのテキストを探します。テキストがないときに失敗させるか、見つかったときに失敗させるかを選べます。リダイレクト後の最終的なURLを指定してください。
• 応答時間：各チェックの応答時間は保存され、モニターページで過去24時間、7日間、30日間のグラフとして表示されます。「Xミリ秒より遅い」といったアラートはありません。アラート送信まででは、アラートが届くまでに何回連続でチェックが失敗する必要があるか（1、2、3、5回）を設定でき、一時的な揺らぎで受信箱が埋まるのを防げます。
• リージョン間の判定不一致：HTTPモニターまたはキーワードモニターがダウンしている間、Baromioはほかの拠点からサイトを再チェックします。2サイクル連続ですべての拠点からサイトに到達できた場合、モニターカードに判定不一致バッジが表示され、インシデントページでその理由が説明されます。アラートや復旧を変えることはなく、ダウンが誤検知である可能性を知らせるだけです。すべてのプランで利用できます。
• ページ速度：HTTPモニターまたはキーワードモニターでページ速度を監視をオンにすると、Google PageSpeed Insights経由でLighthouseを実行します。Freeプランでは1 URLを毎週、Proプランでは5 URLを毎日、Businessプランでは15 URLを毎日チェックします。
• チェック間隔：Freeプランは5分ごと（20モニター）、Proプランは1分ごと（月額9 EUR、30モニター）、Businessプランは30秒ごと（月額29 EUR、100モニター）です。

クライアントサイトごとのチェックリスト

1. トップページにHTTPモニターを設定します。
2. 最も重要なページにキーワードモニターを設定し、実際のコンテンツの一部が欠けたときに失敗するようにします。
3. ホスティングの変更や大きめの更新のたびに、応答時間のグラフを確認します。
4. 更新のたびに、フォーム、ログイン、チェックアウトを手動でテストします。
5. クライアントに障害を伝える前に、自分でサイトを開いて確認します。

出典

• ICANN、Expired Registration Recovery Policy：期限切れ後、レジストラはドメインのDNS名前解決経路を遮断しなければなりません。代わりに表示するランディングページには、登録が期限切れになったことを明記する必要があります。