Webサイト監視の履歴を見ても、「200と表示されているから正常？」「応答時間が急に長くなったのは障害？」「失敗した次の記録が成功なら、いつ復旧した？」と判断に迷うことがあります。監視履歴を読むときは、計測時刻・HTTPステータス・応答時間・失敗理由をセットで確認し、前後の記録と比べることが基本です。
特に重要なのは、200 OKでも遅い応答があり、503はHTTP応答を受け取った失敗で、タイムアウトはコードを取得できない場合があり、未計測は正常とも異常とも断定できないという違いです。最新の結果が200に戻っていても、直前の失敗がなかったことにはなりません。一方、5分おきのチェックが2回失敗したからといって、実際の停止時間が正確に10分だったとも限りません。
この記事では、架空の8件の監視履歴サンプルを使って、一覧表と時系列図の読み方、応答時間の変化、エラー種別の切り分け、平均・P95と失敗率の見方、復旧したと判断する際の注意点を解説します。実際の監視ツールには表示項目の違いがありますが、読み解くための考え方は共通です。死活監視の基本的な仕組みや稼働率の計算方法そのものは既存記事に譲り、ここでは記録をどう解釈するかに絞ります。
監視履歴で最初に確認する4つの情報
履歴の一覧を開いたら、最新の「正常」表示だけを見るのではなく、いつ・どこに・どのようなチェックを行い、何が返ったかを確認します。各行は通常、特定の監視対象に対する一回の計測またはその判定を表すため、前後の行を比較して初めて意味が分かります。
1．計測日時は「いつ観測した結果か」を示す
監視履歴の時刻は、利用者が不具合を体験した時間や、システムで障害が始まった時刻と必ずしも一致しません。監視ツールが実際にチェックを行った時刻、あるいは結果を保存した時刻として表示されることがあり、どちらを記録しているかは製品の仕様によります。
記録を照合するときは、日付だけでなく時・分・秒とタイムゾーンを揃えましょう。日本時間（JST）とUTCを混在させると、同じ事象のログが9時間ずれて見えます。サーバー側のログや利用者の問い合わせ時刻を照合する際は、まず表示タイムゾーンを確認してください。
2．結果とHTTPコードは別の意味を持つ
履歴の「成功」「失敗」は、監視ツールが設定した条件を満たしたかどうかの判定です。一方のHTTPステータスコードは、Webサーバーなどから実際に返された応答の種類を示します。一般的には200 OKは成功応答、404 Not Foundは対象が見つからない状態、503 Service Unavailableはサーバーがリクエストを処理する準備ができていない状態を示します。
ただしリダイレクトの追跡方法、期待するステータス、本文検査の有無によって、同じHTTPコードでも監視の「成功／失敗」の判定が違うことがあります。コード欄だけではなく、その監視で何を成功条件にしているかを確認してください。HTTPステータスの基本的な意味はMDNのステータスコード一覧が参考になります。
3．応答時間は「そのチェックで観測した待ち時間」
応答時間は、監視拠点が対象URLへリクエストを行い、定義された条件まで応答を得るのに要した時間です。ミリ秒（ms）で記録される場合、1000msは1秒に相当します。例えば220msと1450msでは、後者のチェックの方が観測された応答に時間がかかったことが分かります。
ただし測定範囲はツールによって異なります。DNS解決、TLS接続、リダイレクト、本文受信のどこまで含むかによって数値が変わるため、異なる監視サービスの数字を単純比較してはいけません。またHTTP応答が速くても、ブラウザーで画像やJavaScriptを読み込む時間まで速いとは限りません。
4．判定理由・エラー種別で失敗した段階を探す
HTTPコードが取得できた失敗なのか、名前解決エラー、接続拒否、TLSの検証失敗、応答のタイムアウトなのかで、次に調べる場所は違います。例えば503が記録されているなら、少なくともHTTP応答を受け取っています。一方、タイムアウト時はHTTPコードが記録されていないこともあります。
この違いは原因の確定ではなく、調査の入口です。タイムアウトでもサーバー側の処理が遅い場合と監視地点のネットワークで問題が起きた場合があるため、失敗理由と同時刻の別の記録を確認します。どの種類のエラーを表示するか、未取得の項目をどう表すかは利用サービスによって異なります。
監視履歴のサンプル表を実際に読み解く
次の表は架空の企業サイト「example.com」を、説明用に5分おきに観測したと仮定したサンプルです。実際のエンリンクの取得データや管理画面のスクリーンショットではありません。日時は2026年10月20日のJSTとし、結果、HTTPコード、応答時間を読み解く練習用に用意しています。
| 計測時刻（JST） | 結果 | HTTPコード | 応答時間 | 読み取りのポイント |
|---|---|---|---|---|
| 14:00 | 成功 | 200 | 220ms | 基準として見る通常応答 |
| 14:05 | 成功 | 200 | 480ms | 成功だが少し遅い |
| 14:10 | 成功 | 200 | 1450ms | 失敗前に遅延が見られる |
| 14:15 | 失敗 | 503 | 180ms | エラー応答自体は返っている |
| 14:20 | 失敗 | 取得なし | 取得なし | タイムアウトと記録された例 |
| 14:25 | 成功 | 200 | 310ms | この時点では応答が回復 |
| 14:30 | 未計測 | 取得なし | 取得なし | チェック結果が存在しない例 |
| 14:35 | 成功 | 200 | 230ms | 再び成功を観測 |
※「未計測」は図解で説明するために挿入した例で、実際の製品が監視未実行の行を履歴テーブルに表示することを意味しません。製品によっては行そのものがなく、グラフ上の空白や別の状態表示から気づく場合があります。失敗時に応答時間が記録されるかどうかも実装によります。
14:10の200・1450msを「正常だから問題なし」としない
14:10には200 OKが返っていますが、14:00の220msに比べて大幅に遅くなっています。この一行だけでは異常原因は分かりませんが、14:15の503より前に応答が悪化していた可能性を示す手掛かりになります。14:05も480msであり、前後に上昇傾向があるかを確認したくなる並びです。
ただしこの3点だけで「サイトが徐々に悪化した」と断定するのも早計です。単発のページ生成処理や監視地点の通信状況が影響した可能性もあります。別の時間帯や前日同時刻の履歴を見て、普段からよく起きる変化かどうか判断してください。
14:15の503は「速く返ったエラー応答」
14:15は503で失敗し、応答時間は180msです。これは「180msで正常表示できた」という意味ではなく、エラーを示すHTTPレスポンスを短時間で受け取ったことを表します。応答が速いことと、正常な結果が返ったことは別です。
503は一般にサービスがリクエストを処理できない、または準備ができていない状態を表します。過負荷・メンテナンスなどが例として挙げられますが、この一行だけで原因を決めることはできません。同時刻のWebサーバーやアプリケーションのログ、公式メンテナンス情報と照合します。
14:20のタイムアウトではHTTPコードを推測しない
14:20の記録では、監視が応答を待ったものの時間内に結果を得られなかったと仮定しています。この場合、HTTPコードが「取得なし」となることがあります。タイムアウトを自動的に504 Gateway Timeoutと読み替えてはいけません。504はゲートウェイなどが実際に返すHTTPステータスであり、監視ツール自身の待機上限到達とは違います。
また、表ではタイムアウトの応答時間を取得なしとしていますが、監視ツールによっては待機した時間などを別の欄へ表示する場合があります。エラー種別と値の意味を確認し、数字が空欄だから「通信時間が0msだった」と扱わないようにしてください。
14:25の200で「復旧を観測」しても停止時間は未確定
14:25の200は、その時刻のチェックが成功したことを示します。しかし14:20のチェックでタイムアウトした後、実際にいつ復旧したかまでは分かりません。14:21に回復したのか、14:24に回復したのかは、追加の監視ログやサーバー側の記録がなければ特定できません。
同様に、14:10の成功直後から異常が起きたのか、14:15の直前なのかも分かりません。14:15と14:20の失敗を見て、停止時間を機械的に「10分」と決めないでください。詳しい時間計算と稼働率の違いは稼働率の計算記事で扱っています。
14:30の未計測を成功率へ足さない
14:30は、説明用に「計測結果が存在しなかった」と仮定した時刻です。ネットワークや監視基盤側の問題、実行予定の変更、監視停止など、原因はいくつも考えられます。履歴テーブルに行がない場合もあるため、監視設定や実行ログで確認する必要があります。
この時刻を「成功」として数えてしまうと、実際に観測できていない時間の健康状態を過大評価します。逆に、未計測がそのままサイトの停止を証明するわけでもありません。結果を取得できなかった区間は、正常・失敗と別の扱いで整理するのが適切です。
時系列で見ると分かる「失敗の前後」の変化
監視履歴は一行ずつ読むだけでなく、時間の順に並べて確認します。応答時間が先に伸び、その後エラーが発生し、再び200へ戻ったという順序が分かれば、サーバーやアプリケーションのログを調べる時間帯を絞りやすくなります。
確認する順番は「直前の成功→失敗→次の成功」
まず最初の失敗を特定し、その一つ前の成功と、その後の最初の成功を確認します。今回の例なら14:10が最後に確認できる成功、14:15と14:20が失敗、14:25が再び成功した時刻です。これは観測された順番であり、実際の障害開始・終了時刻を正確に特定するものではありません。
次に、失敗より前に応答が遅くなっていないか、失敗が連続しているか、復旧後の応答時間が以前の水準に戻っているかを調べます。単発失敗でも実際の短時間障害だった可能性は残るため、理由を確認せずに捨てないことが重要です。
折れ線グラフの空白には理由がある
応答時間のグラフに点がない場合、タイムアウト、計測未実施、監視対象の停止、表示期間の範囲外などが考えられます。点がない区間を0msとして線で結ぶと、実際には測っていない時間を「非常に高速だった」と誤解させるおそれがあります。
またエラー応答として503が返った場合、製品によっては応答時間の点を表示することがあります。グラフの点に値があることだけでは正常と判断できないため、ステータスコードや失敗マーカーを同じ時系列で見てください。
時刻のずれと検査間隔を読み違えない
監視画面に表示される時刻がJST、サーバーログがUTCなら、同じ事象でも表示時刻が異なります。例えばJST 14:15はUTC 05:15です。時刻変換をしたうえで、タイムゾーンを付けて報告します。時刻同期の誤差がある場合も、秒単位の前後関係を慎重に扱ってください。
検査の設定間隔と実行時刻が完全に一致するとは限りません。実際に保存された実行時刻、処理待ち、データ反映の遅れがある場合、グラフの点が予定どおりの間隔に並ばないことがあります。今回の5分間隔は図解用であり、エンリンクの各プランの実行間隔を表したものではありません。
応答時間の履歴は平均・P95・最大値を分けて読む
応答時間の変化は「遅い値が一度出た」だけで決めつけず、普段の水準、遅い側の値、いつ遅くなったかを確認します。平均とP95では見える特徴が異なるため、それぞれが何を示しているか理解しておきましょう。
ミリ秒表示を秒へ読み替える
履歴に220msと表示されていれば0.22秒、1450msなら1.45秒です。数値の単位を間違えると、遅延の影響を大きく見誤ります。秒からミリ秒へ読み替える場合は1000倍です。監視の画面と、別システムのログで単位が違うときは揃えて比較します。
ただし「1.45秒だから障害」と一律に判断するべきではありません。通常0.2秒のページが急に1.45秒となった場合と、普段から1秒以上かかる処理では意味が異なります。利用者が困る遅さかどうかも別に評価し、過去の同条件での測定値と照合しましょう。
平均が低くても一部の遅いリクエストは隠れる
平均応答時間は、集計対象の測定値の合計を件数で割ったものです。全体の代表値として分かりやすい一方、ごく一部の極端に遅い結果がある場合、「多くは速いが一部だけ大きく遅い」という分布を平均値だけで把握しにくいことがあります。
例えば通常は200〜300msの計測が多いのに、特定の時間帯だけ数秒かかる場合、平均だけを見ていると遅延が目立ちにくいことがあります。グラフのピークや個々の履歴と合わせて確認し、遅い時間帯を特定しましょう。平均値の対象に失敗した計測を含むかはツールの仕様も確認が必要です。
P95は遅い側の傾向を見る参考になる
P95（95パーセンタイル）は、計測結果を小さい順に並べたとき、おおむね95％の値がそれ以下に収まる位置の値を示す指標です。平均と合わせて見ると、一部の遅い応答が全体の水準に埋もれていないか確認しやすくなります。ただし少数のサンプルでは推定が不安定で、具体的な算出方式や扱う母集団は製品によって違います。
Google SRE Workbookでも、遅延を見る際は平均だけでなく95パーセンタイルなどを確認する意義が説明されています。エンリンクの公開機能一覧にも平均・P95応答時間が案内されていますが、応答の測定条件を揃えて比較することが前提です。P95だけで障害原因を自動的に特定できるわけではありません。
直近24時間の推移と履歴の行を行き来する
応答時間の時間帯別グラフでは、どの時間に遅延が増えたかを大まかに把握できます。一方、個々のチェック履歴は具体的な時刻、HTTPコード、判定理由を確認するのに向いています。グラフで異常な時間帯を見つけ、履歴の行からその時刻の失敗を特定し、必要に応じてサーバーログへ進みます。
エンリンクでは直近24時間の応答時間を1時間ごとに見るグラフと、チェックごとの時系列履歴が案内されています。時間帯ごとに集約されたグラフの値と、個別の計測1件の値を同じものとして扱わないようにしましょう。グラフの集計方法や欠測時の表示も確認が必要です。
HTTPコードと失敗理由で調査の方向を整理する
失敗履歴を読むときは、HTTPレスポンスを受け取ったかどうか、受け取っていればどのコードか、受け取っていなければどの段階で失敗したかを区別します。下表は一般的な例であり、原因を確定する一覧表ではありません。
| 履歴に表示される例 | 分かること | 次に確認する候補 |
|---|---|---|
| 200 OK | そのチェックでは成功応答を取得 | 遅延の有無、内容・機能の問題は別途確認 |
| 301・302など | 転送を指示する応答 | 最終到達URL、転送設定、監視の成功条件 |
| 403 Forbidden | アクセスが拒否された応答 | 認証、WAF、監視元の制限 |
| 404 Not Found | 対象リソースが見つからない応答 | URL変更、公開終了、転送の有無 |
| 500 Internal Server Error | サーバー側の内部エラー応答 | アプリケーションやWebサーバーのログ |
| 503 Service Unavailable | サービスが処理できない状態を示す応答 | 負荷、計画メンテナンス、上流の状況 |
| 504 Gateway Timeout | ゲートウェイ側で上流応答を待ち切れない | プロキシー、アプリ、上流への接続 |
| 監視側のタイムアウト | 所定時間までに条件を満たす応答を取得できない | 失敗した段階、監視地点、応答の遅延 |
| DNS・TLSエラー | 名前解決や暗号化通信の確立で失敗 | DNS設定、証明書、通信経路 |
| 未計測・データなし | 判断に使う測定値がない | 実行履歴、監視設定、監視基盤 |
503と504はどちらもエラーでも意味が違う
503 Service Unavailableは、サーバーがリクエストを処理する準備ができていないなどの状態を示すHTTP応答です。一方504 Gateway Timeoutは、ゲートウェイやプロキシーが上流から所定時間内に応答を得られなかったことを示します。両者は同じ「サイト停止」という一語だけでは整理しきれません。
MDNの公式ドキュメントでも、この違いが明示されています。ただし503があるから必ずメモリ不足、504があるから必ずデータベース障害、と原因を一つに決めることはできません。どの装置・プログラムがステータスを返したかと、その時刻のログを調べます。
タイムアウトとDNS・TLSの失敗では見る場所が変わる
名前解決ができなければ接続先を特定する段階で失敗する可能性があります。TLS証明書の検証失敗なら、安全なHTTPS接続が成立しなかった可能性があります。HTTPコードを取得できていない場合、アプリケーションが実際に何を返したかは履歴から分からないことがあります。
タイムアウトは接続待機、最初の応答待機、本文受信など、監視ツールが測定する段階によって解釈が違います。表示されている「失敗理由」と、取得できた項目を区別してください。証明書期限やDNS補助診断が利用できる場合も、それらは原因を確定する証拠ではなく確認の手掛かりです。
200が続いていても内容や操作の不具合は別に調べる
履歴がすべて200でも、画面が真っ白、古いメンテナンス表示が残っている、フォーム送信だけできない、といった問題は起こり得ます。ステータス監視で成功したのは、そのURLが設定された条件でHTTP応答したということです。
「200なのにページが壊れている」ケースは200 OKでもサイトに不具合がある理由で詳しく説明しています。本記事では履歴の解釈に集中し、コンテンツの文字列一致検査やブラウザー操作テストの設定方法は繰り返しません。
障害・復旧履歴とチェック履歴を混同しない
監視サービスによっては、個々のチェック結果のほかに「障害の可能性を記録」「復旧を確認した」といったイベントを別に保存します。同じ画面に並ぶ場合でも、測定された一回の結果と一定の判定条件に基づくイベントは意味が違います。
チェック履歴は一回ごとの観測結果
チェック履歴には、指定URLへの接続・HTTPコード・応答時間・失敗理由など、その時点の計測が記録されます。14:15に503、14:20にタイムアウト、14:25に200という履歴があれば、少なくともそれぞれの時刻の観測が異なっていたことが分かります。
ただし個々の失敗が、そのまま緊急通知や障害イベントとして登録されるとは限りません。単発失敗の扱いや連続失敗の判定方式によって、イベント化される時刻が変わります。監視履歴に失敗が一件あることと、公式な障害報告が一件発生したことを同一視しないようにします。
障害・復旧イベントは判定条件を確認する
ある監視サービスが「連続失敗が一定回数に達したときに障害の可能性として記録する」方式なら、最初の失敗時刻と障害イベントの記録時刻は異なる場合があります。復旧側も成功を何回確認するかなど、製品のルールによって記録の付け方が変わります。
エンリンクの機能一覧には、連続失敗による障害の可能性の記録、障害・復旧の履歴、失敗回数と判定理由の確認が案内されています。一方、利用者が再試行回数やイベント化のしきい値を自由に変えられるとまでは公式説明から確認できません。誤検知と連続失敗の判定では一般的な判断条件を整理しています。
既読や対応完了は復旧の証拠ではない
監視のイベントを管理画面で既読にしても、サイトが自動的に復旧したわけではありません。既読は情報を確認したこと、技術的な復旧は監視対象が再び応答できるようになったこと、業務上の復旧は重要な操作が利用できること、と段階を分けます。
担当者への通知条件や連絡順は、Webサイト監視のアラート設計で詳しく扱っています。履歴を読む目的は、通知が出たことを数えるだけでなく、どの時刻に何が観測されたかを把握して、安全な調査と復旧確認につなげることです。
直近24時間・7日間・14日間の集計の読み方
個々のチェックのほかに、直近24時間や7日間の成功率・応答時間、日別集計などが表示される場合があります。集計の分母と対象期間を理解しないと、数字が良く見えても実際の欠測や一時的な障害を見落とします。
チェック成功率は「測れた検査の成功割合」
監視の成功率は一般に、設定された判定条件に合格したチェックの割合として使われます。ただし再試行を一件として扱うのか、実行した試行をすべて数えるのか、欠測をどう扱うのかはサービスによって異なります。同じ99％でも、何を分母にして計算したかが違えば比較できません。
未計測の時間を無条件に成功として追加してはいけません。また、1分に一回チェックしていた期間と1日2回チェックしていた期間では、短い停止を検知できる機会が違います。履歴を読む際は、設定された監視の頻度と実際の実行記録を確認してください。時間ベースの稼働率の計算は別記事で説明しています。
14日間の日別結果は「どの日に変化が集中したか」を見る
日別の成功率を眺めると、特定の日だけ失敗が多い、数日続けて同じ時間帯に遅延が出る、といった傾向を見つけやすくなります。ただし日別の割合だけでは、失敗したURLや時刻、返されたHTTPコードを特定できません。
気になる日を見つけたら、その日のチェック履歴へ戻り、失敗した時刻とコード、応答時間を確認します。公開作業や保守作業があった日なら、同じ時刻の作業記録と比較します。日別結果は調査を始めるための入口と考えましょう。
平均・P95と時系列のグラフを並べる
平均だけが高い場合でも、特定の短時間に極端な遅延があったのか、終日少しずつ遅かったのかで対応が違います。P95が目立って大きければ一部の遅い測定に注目する手掛かりになりますが、原因の特定には時間帯やエラーの履歴が必要です。
エンリンクの公式機能一覧では直近24時間・7日間の監視集計、平均・P95応答時間、直近24時間の応答速度推移、直近14日間の日別成功率が案内されています。24時間の推移グラフと14日間の集計は、同じ粒度のデータではありません。期間と単位を確認して読み比べましょう。
監視履歴に異常があったときの確認手順
気になる履歴を見つけたら、最初からサーバーを再起動したり設定を変えたりせず、観測できた事実を整理します。履歴の一行、前後の時系列、実際の公開画面、サーバー側の記録を順に見ていくと、誤った原因判断を避けやすくなります。
手順1：対象URL・時刻・判定理由を控える
まず対象サイト名、正式URL、計測時刻とタイムゾーン、HTTPコード、応答時間、判定理由を記録します。複数サイトを管理している場合、別のURLのエラーが混ざっていないか確認してください。サイト名だけでなく、最終到達URLやホスト名も必要に応じて照合します。
担当者への引継ぎでは、画面に表示された事実と「サーバーが過負荷かもしれない」といった推測を分けて伝えます。HTTPコードが取得できていない場合は、適当なエラーコードを補わず「タイムアウト・コード取得なし」など観測した内容で記録します。
手順2：最初の失敗の前後数件を見る
失敗した行だけを切り出すのではなく、直前の正常結果、連続失敗の有無、次の成功、復旧後の応答時間を確認します。例えば今回のサンプルなら14:10から14:25までを一つのまとまりとして眺め、14:30の欠測は別の事象として扱います。
応答時間が失敗前から増えていたか、同じHTTPコードが続いているかを確かめます。別の監視地点や別のURLでも同時に失敗している場合は、その情報も照合すると、経路固有か共通基盤かを調べる手掛かりになります。
手順3：実際の画面と公式障害情報を確認する
管理権限のある公開サイトなら、通常のブラウザーや別回線から現在の表示を安全に確認します。いま正常に見えても、履歴に記録された過去の障害が存在しなかった証明にはなりません。フォーム送信や決済などの状態変更操作を、確認のために無断実行しないでください。
サーバー会社やクラウド事業者が公式障害情報・メンテナンス情報を公開している場合は、発生時刻と対象サービスを照合します。エンリンクの機能一覧では、対応する事業者の公式障害情報と登録ホスト識別情報を照合する機能が案内されていますが、公式記事と自社環境が関連するかは管理者の確認が必要です。
手順4：権限のある担当者がログを照合する
外部監視だけで原因が分からない場合、権限のある担当者がWebサーバーのアクセスログ、アプリケーションエラー、データベースやネットワークの記録、設定変更履歴を確認します。例えば14:15の503前後に実際のメンテナンスや負荷増加があったかを調べます。
一つのエラー記録だけで原因を決めず、同時刻の関連する事象を複数確認します。AWS CloudWatch Syntheticsの公式資料でも、失敗した実行と成功した実行のログ、詳細データを比較する方法が案内されています。ただしブラウザースクリーンショットやHARなどの情報がすべての監視サービスで取得できるわけではありません。
手順5：外部での復旧と重要操作の復旧を分けて記録する
調査後は、外形監視の結果が正常に戻っているか、利用者が必要とするページが表示されるか、必要に応じて重要な操作が安全に確認できたかを整理します。HTTPで200へ戻ったことだけを根拠に、すべての機能の復旧を断言しないようにしましょう。
復旧時刻として残す数字も、実際の処理復旧時刻なのか、最初に正常なチェックを観測した時刻なのか区別します。どの時刻を記録したかを明示すれば、監視が観測できなかった間の推測を事実として扱う危険を減らせます。
監視履歴を読むときによくある5つの誤解
履歴の数値は分かりやすく表示されていても、単独では意味を誤解しやすい情報です。監視の記録と、実際の利用者体験の差を意識すると、原因の断定や過大評価を避けられます。
誤解1：200ならサイトの全機能が正常だった
200 OKはHTTPリクエストの成功応答です。対象URLのHTMLは返っていても、JavaScriptで動く画面やログイン、フォームの送信などが失敗している可能性があります。重要な操作が正常だったかは別の安全な方法で確認する必要があります。
監視履歴を読むときは「そのURLで、設定された監視条件が成功した」という範囲に限定して説明しましょう。ページ内容の異常についてはコンテンツ監視の記事も参考になります。
誤解2：応答時間が短いほどサービスが正常だった
例えば503が180msで返ったとしても、失敗応答を速く受け取っただけです。成功と失敗の判定を確認せず、速さだけで評価すると誤った結論になります。応答時間はHTTPコードや結果と組み合わせて読む必要があります。
またHTTPの応答時間と、ブラウザーで画面を描画するまでの時間は別です。外部の分析サービスが計測するページ全体の読み込み時間と比較する場合も、測定対象が一致するか確認しましょう。
誤解3：記録がない時間は問題がなかった
未計測の時間は、サイトが正常だったとも停止していたとも断定できません。計測間隔の間の時間に加え、監視基盤が実行できなかった、監視設定を停止していた、といったケースも区別する必要があります。
監視を行っていない時間まで正常稼働の証拠として扱うことはできません。一覧に欠測が見えない場合でも、実行予定と実際の履歴件数を照合して初めて、記録の抜けに気づけることがあります。
誤解4：連続した失敗の数だけで停止時間が分かる
5分間隔で連続して失敗した履歴があると、停止時間を単純に計算したくなります。しかし失敗したチェック時刻の前後にも状態が変わっている可能性があり、実際の開始・終了時刻までは把握できません。監視時刻は障害期間そのものではなく、観測した点です。
連続失敗の数は、どの程度継続して異常を観測したかを示す参考情報です。計測間隔と監視設定を併記し、停止時間の推定と確定値を区別してください。
誤解5：最新結果が正常なら過去の失敗は無視できる
いま正常に表示されていても、前の時間帯に失敗や大きな遅延があった事実は残ります。特に同じ時刻の異常が繰り返されるなら、定期処理、更新作業、負荷の集中といった原因を調べる価値があります。
履歴を残す目的は、現在正常かどうかを見るだけではありません。問題がいつ、どのような形で現れ、どう回復したかを説明できるようにすることです。過去の失敗を単純に消さず、事実と原因候補を分けて確認しましょう。
エンリンクで確認できる監視履歴と画面の使い分け
エンリンクの公開機能一覧には、チェック日時・結果・HTTPコード・応答時間・判定理由の時系列履歴、障害・復旧の履歴、24時間・7日間の集計、平均・P95、直近24時間の速度推移、14日間の日別成功率が案内されています。これらは異なる観測粒度の情報なので、目的に合わせて行き来して確認すると読み解きやすくなります。
最初は登録サイトの一覧から要確認の対象を探す
エンリンクでは、登録サイトごとの正常応答・障害の可能性・監視不可・停止中などを一覧に表示する機能が案内されています。まず今どのサイトに注意が必要かを確認し、該当するサイトの詳細・履歴を開くという流れが考えられます。
ただし管理画面の表示文言や配置は変更される場合があります。この記事の表や図解は実際のエンリンク管理画面の再現ではありません。公式機能一覧で案内されている情報の種類をもとにした、監視履歴の読み解き例です。
詳細履歴でHTTPコード・時刻・判定理由を確認する
チェック結果の詳細では、正常・失敗の判定だけでなく、HTTPコード、応答時間、失敗回数や判定理由を確認することができます。気になる結果があれば、同じサイトの前後の履歴へ戻り、最初の失敗と最初の復旧観測を探してください。
単発失敗と継続失敗をどう判定するかは監視サービスの実装によります。エンリンクの機能一覧では連続失敗の記録が説明されていますが、即時再試行回数や自由なタイムアウト設定まで提供しているとは確認できません。最新の機能一覧で確認できる範囲と、一般的な監視の設計例を区別します。
24時間グラフと14日間集計を読み違えない
直近24時間の応答時間グラフは遅い時間帯を見つける参考に、14日間の日別成功率は日ごとの変化を探す参考になります。気になる日時が見つかっても、集約グラフから個別のエラーを断定せず、実際のチェック履歴や障害・復旧の記録で確認しましょう。
24時間・7日間の監視集計も、実際に実施したチェックの件数や成功・失敗に基づく情報です。未計測期間と混同しないことが重要です。各プランの登録可能サイト数や監視間隔は料金プランで確認できます。監視設定の間隔は、障害を何分以内に必ず見つけるかの保証ではありません。
無料プランから履歴の意味を確認する
2026年10月24日時点の公式料金ページでは、無料プランは最大5サイトを登録でき、定期監視は1日2回です。有料プランは契約内容に応じて最短15分・5分・1分の監視間隔が案内されています。監視間隔の違いにより、蓄積されるチェック件数や短時間異常の見つけやすさが変わる場合があります。
まず自分が管理するサイトのHTTPコードと応答時間、過去の成功・失敗を確認したい場合は、エンリンクの無料アカウント登録から始められます。ただし無料プランの「1日2回」と、この記事に登場する説明用の「5分間隔の履歴サンプル」は異なります。図解の数値を実際のプラン仕様と誤解しないでください。
監視履歴の見方についてよくある質問
履歴を読み解くときに生じやすい疑問を、HTTPコードと応答時間、記録の有無、障害・復旧の判断に分けて回答します。どの情報が実際に観測されたもので、どこからが推測かを区別することが重要です。
監視履歴に200と出ていれば、サイトは正常だったのですか？
そのチェックで成功応答を取得したことは示しますが、サイト全体の正常動作までは分かりません。確認したURLと成功条件を見て、表示内容や重要な操作が必要なら別の方法で確認してください。
応答時間が1000msを超えたら障害ですか？
1000msは1秒ですが、超えただけで障害とは断定できません。普段の応答時間や利用者の許容範囲と比較する必要があります。また遅い応答がHTTPエラーの場合もあるため、成功・失敗とHTTPコードをセットで確認します。
タイムアウトの履歴でHTTPコードが空白なのはなぜですか？
監視側が応答を受け取れず、HTTPステータスを取得できなかった可能性があります。通信のどの段階で失敗したかは判定理由を確認してください。空欄だからHTTP 504だった、応答時間が0msだったとは判断できません。
最新結果が成功なのに障害履歴が残っているのはなぜですか？
現在のチェックが成功していても、過去に失敗や障害判定が記録されていた可能性があるためです。現在状態と過去の出来事は別です。発生・復旧イベントと個別のチェック履歴を見比べてください。
グラフのデータがない時間帯はサイトが停止していたのでしょうか？
データがないだけでは判断できません。監視停止、未実行、データ反映の遅れ、タイムアウトによる記録の形式の違いなどを確認します。欠測は、正常でも障害確定でもない別の状態として扱います。
5分おきに2回失敗したら10分間の停止ですか？
正確に10分停止したとは言えません。二つの失敗した観測点があることは分かりますが、実際の障害開始と復旧の時刻はその間や前後にあり得ます。追加の詳細ログがない限り、停止時間を確定値として扱わないことが大切です。
平均応答時間とP95はどちらを見るべきですか？
両方を見ると役立ちます。平均は全体の傾向、P95は遅い側の値の傾向を把握するための参考になります。値が変わった時間帯を時系列で調べ、必要なら個別の遅い履歴やサーバー側のログを確認してください。
複数サイトの監視履歴はまとめて読めますか？
サイトの状態を一覧にまとめられるサービスはありますが、履歴の判定は対象URLや監視間隔によって異なります。エンリンクではサイト別状態の一覧と個別の履歴が案内されています。複数サイトの管理方法は複数サイトを一元管理する方法にまとめています。
まとめ：監視履歴は数字を単独で見ず、前後の流れで判断する
Webサイト監視の履歴は、計測時刻、成功・失敗、HTTPコード、応答時間、判定理由を組み合わせて読むと意味が分かります。200でも応答が遅いことがあり、503はエラー応答が返ったこと、タイムアウトはコードを受け取れない可能性があること、未計測は状態が分からないことを示します。
異常が見つかったら、直前の成功→失敗した検査→次の成功という順序を確認し、時系列グラフの遅延や欠測を照合してください。チェックの点と点の間は観測できていないこともあるため、停止開始・復旧の時刻を推測で確定しないようにします。平均とP95、日別の成功率は変化を探す入口として使い、原因の調査には個別の履歴へ戻ることが大切です。
エンリンクではHTTP/HTTPSの監視履歴、HTTPコード、応答時間、障害・復旧の記録、平均・P95などの情報が案内されています。5サイトまで無料で利用できるエンリンクで、まず管理しているWebサイトの履歴を確認し、気になる時間帯の記録を読み解くところから始められます。
参考にした一次資料：Google Cloud「稼働時間チェックを管理する」、Google Cloud「Uptime-check metrics」、AWS「Canaryの統計・詳細」、Google SRE Workbook「Monitoring」、MDN「HTTPレスポンスステータスコード」、MDN「504 Gateway Timeout」（最終確認：2026年10月24日）。
