「Webサイトが時々落ちる」「開き直すと正常に表示される」「特定の時間だけ接続できない」という症状では、一時的なサーバー負荷・定期処理・アプリケーションの不安定さ・DNSやCDNなどの経路差・アクセス制御が原因候補になります。重要なのは、表示できなかったときの正確な時刻・URL・エラーの種類を記録し、正常だった時刻と比較して再発条件を絞ることです。
断続的な障害は、担当者が確認した時には自然復旧しているため、原因が見つからないまま放置されやすい問題です。外部からの定期監視で「成功→失敗→成功」の変化を残し、同じ時刻のサーバー・アプリ・ネットワークの記録と照合する方法が基本となります。ただし監視間隔の間に発生して終わった障害は見逃すことがあり、1分間隔でもすべての瞬断を保証できるわけではありません。
この記事では、企業サイト・ECサイト・採用サイト・Webサービスの担当者に向けて、時々落ちる原因の見分け方、具体的な監視記録の例、短時間障害を検知する考え方、実際の調査手順を解説します。HTTPの500番台エラーを一つずつ修正する方法や死活監視の誤検知と再試行条件の設計そのものは別の記事に分け、ここでは繰り返す不安定な状態をどう発見し原因候補を絞るかに限定します。
Webサイトが時々落ちるとは？まず症状を3つに分ける
断続的な障害は「落ちる」という一語では原因を特定できません。同じURLでも時間帯で応答が変わるのか、特定の利用者だけ失敗するのか、ページの表示はできるのに操作だけ失敗するのかを最初に区別します。
一時的にアクセスできず、しばらくすると復旧する
例えば朝は問題なく開けるのに、昼前に接続がタイムアウトし、数分後に同じURLを開くと表示される状態です。継続的な全面停止ではなく、成功と失敗が入れ替わることが特徴です。サーバー処理が一時的に遅くなる場合もあれば、ネットワークの特定経路だけに問題がある場合もあります。
次に見るべき情報は、表示できなかった時刻、ブラウザーのエラー、HTTPステータス、同時刻の応答時間です。発生時刻が不明だと後から大量のログを調べることになるため、まず症状を短くても記録します。復旧した瞬間の再確認で正常になったことは、直前に異常がなかった証明にはなりません。
自分の端末では落ちるが、ほかの人は開ける
同じ時刻にスマートフォンのモバイル回線で失敗し、社内の有線回線では成功することがあります。地域や通信事業者、利用中のDNS、CDNの配信拠点、WAFの制御条件などが異なると、利用者によって見える状態に差が出る可能性があります。
このとき「社内PCで開けたから障害ではない」と判断するのは早計です。影響する利用者の条件を切り分ける必要があります。反対に、一人の端末だけで再現する場合も、キャッシュやブラウザー拡張機能、端末のネットワーク設定などの影響が考えられます。複数の回線や端末での観測結果を同じ時刻に揃えて比べましょう。
ページは表示されるが、特定の操作だけ時々失敗する
トップページは常に200 OKでも、ログイン・問い合わせ送信・決済・予約などの操作が混雑時だけ失敗する場合があります。このケースでは、公開URLへの通常のHTTP監視だけでは問題を検知できないことがあります。通信が成功したことと、利用者の目的が完了したことは別だからです。
まず失敗した「操作の名前」と「操作時刻」を記録し、関連するAPIやアプリケーションのログへつなげます。本番で送信や決済を繰り返して再現させることは避け、安全なテスト環境や許可された検証手段で確認してください。200 OKでもサイトが壊れている場合の確認方法では、表示内容と操作の違いを詳しく扱っています。
Webサイトが断続的に落ちる代表的な原因7つ
断続的な失敗の原因は一つとは限らず、表に見える症状だけで断定できません。どの条件で起きたかと、同時刻に確認できるサーバー側の事実を組み合わせることで、優先して調べる候補を絞ります。
1．アクセス集中で処理が一時的に追いつかない
広告配信、キャンペーン開始、ニュース掲載、メールマガジンからの流入などで短時間にアクセスが集中すると、サーバーやアプリケーションの処理能力が足りず、待ち時間が増えたり一部のリクエストが失敗したりする場合があります。アクセスが落ち着いた後は正常に戻るため「時々落ちる」ように見えます。
この仮説を確かめるには、失敗前後のリクエスト数、応答時間、CPU・メモリ、接続数、処理待ちの長さを同じ時刻で比較します。ただしアクセス数が増えているだけでは原因と断定できません。該当サーバーの処理上限やエラーログと一致するか確認してください。根拠なくタイムアウトを長くするだけでは、利用者にとって遅い状態が残る可能性があります。
2．定期バッチ・バックアップが同じ時間に負荷をかける
毎日決まった時間、週末、月初などに不具合が繰り返される場合は、バックアップ、データ集計、定期更新、メール処理、外部システムとの同期などが動いていないか確認します。通常のサイト閲覧と同じデータベースやストレージを使う処理が重なると、一時的に応答が遅くなる可能性があります。
例えば毎朝9時台だけHTTPのタイムアウトが増えるなら、同じ時間に動くジョブの開始・終了時刻を確認する価値があります。ただし毎日同じ時間だからバッチが原因とは限りません。時間帯による利用者数の増加や外部サービスの混雑も考えられるため、実行ログと監視の失敗時刻を重ねて調べます。
3．アプリケーションやデータベース接続が不安定になる
Webアプリケーションが処理を抱え込み、特定の条件で接続待ちや応答遅延が起きる場合があります。データベースの接続数が上限に達する、重い検索処理が集中する、アプリケーションのプロセスが再起動される、といったことが断続的な失敗につながる可能性があります。
外部監視からは503やタイムアウトとして現れても、どの内部処理が原因かは確定できません。アプリケーションログ、データベースの接続数・遅いクエリ、プロセスの再起動記録などを、権限を持つ担当者が確認する必要があります。ログに個人情報や認証トークンが含まれる場合は閲覧範囲を限定してください。
4．デプロイ・再起動・自動スケーリングの切り替え時に失敗する
更新作業の直後やサーバーの自動切り替え中だけアクセスできないことがあります。新しいアプリケーションの起動が完了する前にリクエストが届く、処理中の接続が切れる、複数のサーバーの準備状況が揃わないなど、切り替えの一時的な不整合が考えられます。
発生時刻をリリース、デプロイ、プロセス再起動、オートスケールの記録と照合します。ただし自動スケーリングを利用しているだけで障害が起こるわけではありません。該当時刻にどのインスタンスへリクエストが振り分けられたか、起動・停止の時刻と一致するかを確認しましょう。運用中の本番設定を原因未確認のまま一斉に変更するのは避けます。
5．CDN・ロードバランサー・一部のサーバーだけに問題がある
複数のWebサーバーへリクエストを分散している場合、正常なサーバーと不調なサーバーが混在すると、アクセス先によって成功と失敗が交互に現れる可能性があります。CDNの一部の拠点や、オリジンサーバーへの接続経路だけに問題がある場合も、場所や時刻によって症状が変わります。
確認したいのは、失敗時の最終到達先、サーバー識別情報、ロードバランサーのヘルスチェック、CDNのログと同時刻の応答です。Cloudflareの公式資料でも、502・504の調査ではオリジン側の応答かCloudflare側かを分けて確認する必要性が説明されています。Cloudflareの502・504調査資料を参照してください。
6．DNS・ネットワーク経路が一部の利用者で不安定になる
同じURLでも、利用者のネットワークや名前解決結果によって到達先が変わる場合があります。DNSの設定変更、特定回線の通信障害、名前解決の一時的な失敗などが起こると、一部の利用者だけ接続できず、別の環境では正常に見えることがあります。
一回のDNSエラーを見てすぐ設定を変更するのではなく、どの回線・地域・時刻で失敗したかを確認します。DNSの回答内容、TTL、接続先IPの変化、事業者の公式障害情報などを照合すると候補を絞りやすくなります。症状が解消していても、変更時刻と失敗の時刻を残しておくと次の再発時に役立ちます。
7．WAF・Bot対策・アクセス制限が特定の通信だけ拒否する
セキュリティ設定により、特定のIPアドレスやUser-Agent、地域、リクエストの傾向だけが制限される場合があります。担当者のPCでは正常なのに、ある利用者や監視サービスからのリクエストで403などが返る状態は、その例です。
この場合、監視地点に対する拒否なのか、一般利用者も同じ条件で拒否されているのかを区別してください。WAFの検知ログやアクセス制御の変更履歴を確認します。通知を止めるためにセキュリティ保護を全面解除するのは避け、正当なアクセスと異常な通信を安全に区別する方法を検討します。
症状と発生パターンから優先する調査先を決める
原因を調べるときは、最初からすべてのサーバー設定を確認するよりも、再発する時間帯や条件を分類する方が効率的です。以下は症状から調査先を選ぶための目安で、どのケースも原因を断定する表ではありません。
| 観測した発生パターン | 原因候補 | 照合したい証拠 |
|---|---|---|
| 昼休み・広告流入の直後 | アクセス集中、処理待ち | リクエスト数、応答時間、負荷指標 |
| 毎朝・毎夜のほぼ同時刻 | 定期ジョブ、バックアップ、時間帯負荷 | ジョブ実行履歴、サーバー負荷 |
| 更新・デプロイ直後だけ | 起動中の処理、切り替え、一部インスタンス不調 | リリース時刻、プロセス記録、接続先 |
| 特定の地域・回線だけ | DNS、CDN、ネットワーク経路、WAF | 地域別の結果、アクセス制御・DNSログ |
| 毎回ではなく数回に一度 | 一部サーバーの問題、処理負荷のばらつき | 応答先識別情報、サーバー別エラー率 |
| ページは開くが操作だけ失敗 | API、認証、DB接続、アプリ処理 | 操作時刻、API結果、アプリログ |
| 監視拠点だけ失敗し利用者は正常 | 監視経路、監視設定、拠点側の問題 | 別地点の同時チェック、アクセスログ |
毎日同じ時間なら開始・終了時刻を合わせる
例えば9時ちょうどではなく、9時03分から9時07分だけ失敗が多い場合、その数分に動いていた処理を探します。監視のタイムゾーンとサーバーログのタイムゾーンを揃え、開始時刻だけでなく終了時刻も照合することが重要です。
時間帯が一致することは手掛かりですが、因果関係の証明ではありません。特定処理の負荷と応答遅延が同時に増えているなど、複数の証拠を揃えて判断してください。変更が必要になった場合は、担当者の権限と影響範囲を確認し、安全な検証を行います。
特定の地域だけ失敗するなら同時刻の観測で比較する
東京の監視地点は正常、大阪の利用者は失敗、海外拠点では成功というように、場所によって状態が異なる場合があります。異なる時刻の結果を単純に比較すると、一時的な障害が自然復旧しただけなのか、地域差があるのか分かりません。
できれば同時刻付近の複数地点で同じ公開URLを確認します。異なるIP、経路、CDNの配信拠点、アクセス制御が関係していないかを調べます。複数地点の監視機能はすべての製品にあるわけではないため、必要な場合は対応するツールや許可された手動確認を検討してください。
特定ページだけ失敗するなら共通部分と差を探す
トップページは常に開くのに、商品一覧や求人検索ページだけ断続的に失敗する場合があります。両者で共通するWebサーバーと、片方だけが利用するデータベース問い合わせや外部APIの違いに注目すると、調査の候補を絞りやすくなります。
ただし同じサーバーを使っているという理由だけで、すべての画面が同じ障害になるとは限りません。監視するURLの設計や重要ページの優先順位は監視URLの選び方で説明しています。本記事では、失敗するページと正常なページの差を「原因を絞る証拠」として使います。
短時間の障害は定期監視の間に発生すると見逃される
断続的な障害を調べるとき、監視間隔は重要です。ただし短くすれば必ず発見できるという意味ではありません。監視は連続した全時間を録画しているわけではなく、設定した時点の応答を観測しているためです。
5分間隔では1分半の停止が記録に残らない場合がある
説明用に、10時00分と10時05分に定期チェックを行い、10時01分10秒から10時02分40秒まで90秒間、サイトが接続できなかったと仮定します。10時00分と10時05分のチェックがどちらも正常なら、その間の停止は外部監視の記録に現れない可能性があります。
この例では、実際に不具合があってもチェック結果は2回とも成功です。チェック成功率が100％だったとしても、利用者への影響がゼロだったと保証することはできません。障害が起きている時刻とチェック実行時刻が重ならなければ、失敗を観測できないからです。
1分間隔でもすべての瞬断を記録できるわけではない
同じ90秒の停止では1分間隔の監視が失敗を観測できる可能性は高まりますが、さらに短い一時障害や、チェック間に始まって終わる事象は見逃す場合があります。また複数地点の経路が違えば、監視に成功しても一部の利用者だけが失敗している可能性があります。
監視頻度を選ぶ際は「最短で何分間隔にできるか」と「何分以内の障害を必ず検知できるか」を分けて考えてください。エンリンクでも、公開されている監視間隔は検知までの時間を保証するものではありません。短い停止を証明したいなら監視履歴以外のアクセスログや利用者の報告も必要です。
失敗を観測した時刻は障害の開始時刻ではない
チェック時刻が10時02分で、そこで失敗を観測したとしても、実際にサイトがいつから落ちていたかは分かりません。前の成功と次の成功の間で状態が変化した可能性があります。失敗したチェック回数に監視間隔を掛けただけでは、正確な停止時間を求められません。
監視履歴から分かるのは「この時刻にこの条件では失敗した」という事実です。稼働率の数字と停止時間の計算はWebサイトの稼働率を計算する方法にまとめているため、ここでは時刻を実際の障害原因の調査につなげることを重視します。
断続的な障害を確認する監視履歴のサンプル
次の表は、ある公開サイトが短時間で不安定になったと仮定した架空の監視記録です。実際のエンリンク利用者のデータではなく、管理画面の実物を再現したものでもありません。時刻はすべて日本時間（JST）で、同じURLを説明用に5分間隔でチェックした例です。
| 時刻（JST） | 結果 | HTTPコード | 応答時間 | 調査の手掛かり |
|---|---|---|---|---|
| 11:00 | 成功 | 200 | 220ms | 通常時に近い応答 |
| 11:05 | 成功 | 200 | 1900ms | 成功だが遅延を観測 |
| 11:10 | 失敗 | 503 | 160ms | エラー応答自体は返った |
| 11:15 | 成功 | 200 | 240ms | この時刻には応答が回復 |
| 11:20 | 失敗 | 取得なし | 取得なし | タイムアウトの例 |
| 11:25 | 成功 | 200 | 300ms | 再度成功を観測 |
| 11:30 | 成功 | 200 | 210ms | 引き続き成功を観測 |
※タイムアウト時の応答時間やエラーの表示方法は製品ごとに異なります。この例の「取得なし」は観測できなかった項目を表しており、0msやHTTP 504を意味しません。5分間隔はこの表を説明するための仮定で、エンリンクのすべてのプランに共通する仕様ではありません。
失敗前の11:05に応答時間が伸びている
11時05分には200が返っていますが、応答時間は1900msで、11時00分の220msより長くなっています。これはサーバー負荷が高かった可能性などを考える手掛かりになります。ただし一件の遅い応答だけで「負荷集中が原因」と確定できません。
同時刻のアクセス数、アプリケーションの処理時間、CPU・メモリ、データベースの待機数などを調べます。監視の時系列に先行する遅延があるかを見れば、失敗してから突然問題が始まったのか、以前から兆候があったのかを調べやすくなります。
11:10の503と11:20のタイムアウトは同じ失敗とは限らない
503はHTTPとしてエラー応答を取得した例です。一方、11時20分は監視が待機上限内にHTTP応答を得られなかったという例で、コードを取得できていません。この二つを「500系エラーが2回」とまとめると、調査の入口を誤ります。
時々落ちるという症状が同じでも、サーバー側でエラー応答を作っている場合と、監視地点まで応答が届いていない場合では確認すべき情報が異なります。HTTPコードごとの一般的な修正方法へ広げるのではなく、まず失敗の種類と時刻を正確に区別してください。
11:15と11:25の成功は「断続的だった」ことの手掛かり
11時10分の失敗後に11時15分は成功し、11時20分には再び失敗しています。観測された結果が交互になっているため、少なくとも単一の継続的な全面停止だけでは説明できない可能性があります。この並びは、断続的な問題の調査を始める手掛かりになります。
しかし実際に11時11分から11時14分まで連続で正常だったとは、チェック結果だけでは分かりません。正確な障害開始・終了時間、利用者への影響範囲、同じ原因かどうかは別の記録が必要です。監視履歴の読み方では、各行の数値を詳しく解説しています。
失敗の頻度だけで原因を断定しない
この7件では成功と失敗が混在していますが、サンプル数が少ないため、恒常的な傾向や発生確率まで判断できません。日別・時間帯別の履歴や、同時刻の関連ログを追加で確認する必要があります。観測できていない時間に何があったかは、記録がなければ不明です。
監視の間隔を短くすれば追加の失敗が見つかる可能性はありますが、チェックした時間以外の事象をすべて証明できるわけではありません。利用者からの問い合わせ時刻や障害発生時の操作ログも、適切に保管されていれば重要な情報です。
本当にサイトが落ちたのか、監視地点の問題なのかを切り分ける
監視で失敗したとき、必ずしもサイト全体が停止したとは限りません。Google Cloud Monitoringの公式資料でも、複数の監視地点のうち一地点だけが失敗するケースがあり、ネットワークの一時的な問題などを疑う説明があります。Google Cloudの監視チェック調査資料を参照してください。
同時刻に別の回線や地点で開けたかを確認する
複数の観測地点があるなら、同じ時刻・URLで失敗した地点と成功した地点を比較します。全地点で失敗している場合は、共通する公開サービスへの影響を疑う材料になります。一地点だけで失敗している場合は、そこからの通信経路やアクセス制御などを調べます。
ただし一地点だけであっても、その地域の利用者が本当に困っている可能性はあります。「全部の地点で失敗しなければ障害ではない」という判断は不適切です。監視拠点の結果を利用者の地域・通信環境と対応づけて解釈しましょう。
HTTP応答があったか、接続前に失敗したかを確認する
503のようにHTTPコードが残っている場合、少なくとも監視側はHTTP応答を受け取っています。DNSの名前解決ができなかった、TCP接続を拒否された、TLS接続が成立しなかった、HTTP応答を待ち切れなかった場合は、それぞれ失敗した段階が違います。
エラーコードが空欄だったことを自動的に500や504へ読み替えてはいけません。実際の判定理由と取得できた項目を確認します。Google Cloudの公式ドキュメントでも接続拒否、名前解決、403、404、応答タイムアウトが異なるチェック失敗例として整理されています。
監視の一回の失敗を「誤検知」と決めつけない
次の監視が成功した場合、最初の失敗を「誤検知」と呼びたくなります。しかし実際に数十秒だけサイトが停止した可能性もあります。再試行成功は追加の観測結果であり、最初の失敗が利用者に影響しなかったという証明ではありません。
失敗した時刻のアクセスログ、サーバー側のエラー、利用者からの報告を照合します。通知の回数を減らす設定と、短時間障害を見逃さない調査は別です。再試行・連続失敗の判定設計は別記事にまとめているため、本記事では記録を残すことを重視します。
正常な結果が続いても特定の機能が失敗していないか確認する
対象URLが200を返していても、利用者が必要とするログイン、フォーム送信、予約完了などが失敗している可能性があります。サイトの「死活監視が正常」と「利用者が問題なく業務を完了できた」は同じではありません。
この場合は、問題が起きた操作とその時刻を特定し、関連APIやアプリケーション側のログを確認します。通常のHTTP監視で操作まで自動確認できるとは限らないため、必要なら安全なブラウザー操作テストなど別の手段を検討してください。
Webサイトが時々落ちる原因を調べる6つの手順
一時的に復旧する問題では、症状が再現していないときにも役立つ情報を集めることが重要です。まず読み取り中心の確認で記録を揃え、影響範囲と原因候補を調べてから、権限のある担当者が必要な修正を検討します。
手順1：URL・発生時刻・画面のエラーを記録する
最初に、失敗したURL、発生した日時とタイムゾーン、利用者が行った操作、表示されたメッセージ、端末・ブラウザー・回線を整理します。「時々落ちる」だけでなく「10時35分ごろに求人検索画面で約30秒間タイムアウトした」といった具体的な情報があると、その時間帯のログを探しやすくなります。
個人情報が含まれる画面のスクリーンショットは、必要な範囲で取り扱いを限定してください。発生した時刻が推定である場合は「ごろ」と書き、実測の監視時刻と混同しないようにします。
手順2：外形監視の成功・失敗を時間順に並べる
同じURLの監視履歴から、発生前の正常応答、最初の失敗、その後の成功、再び失敗した時刻を探します。HTTPコードだけでなく、応答時間やタイムアウトなどの判定理由を確認します。グラフにデータがない場合も、未計測・タイムアウト・監視停止の違いを調べます。
監視による失敗が発見できなかったとしても、利用者の報告を否定する材料にはなりません。チェック間に起きた障害や、監視地点と異なる地域・機能で起きた問題を考えます。観測時刻から障害の期間を厳密に確定できないことも記録してください。
手順3：アクセス集中・バッチ・更新履歴を同じ時刻に重ねる
失敗が増えた時間帯を、アクセスログ、CPU・メモリ、データベースの接続状況、定期ジョブ、リリース履歴と比べます。毎日同じ時間なら定期処理を、更新直後だけなら変更内容や再起動履歴を、広告掲載直後ならアクセス量の増加を優先して確認します。
ただし別々の記録が同じ時刻にあることは、直接の原因を確定する証拠ではありません。例えば負荷増加とタイムアウトが一致しても、どの処理が待ち時間を生んだかは追加の調査が必要です。Microsoft Azure Well-Architectedの公式ガイドでも、ログ・メトリクス・トレースを時刻や識別子で関連づけて調査する考え方が説明されています。
手順4：地域・回線・サーバーの違いを確認する
複数のサーバーへリクエストを分散しているなら、どのサーバーが応答したかをログで調べます。特定サーバーで失敗が集中していないか、CDN経由だけ失敗していないか、特定回線のDNS応答が変化していないかなど、観測条件をそろえて比べます。
監視拠点が一つだけの場合、地域差を断定することはできません。必要なら別の正当な回線・地点からの確認結果を追加し、利用者の影響条件を把握します。管理していない他人のサイトを大量の自動リクエストで調べることや、負荷をかけて障害を再現する行為は避けます。
手順5：エラーが出た処理のログを権限のある担当者が確認する
外部からの監視で原因候補を絞ったら、アプリケーション、Webサーバー、ロードバランサー、データベースなど、該当する構成要素のログを確認します。エラーコード、タイムアウト、再起動、接続上限、遅い処理など、失敗時刻と一致する記録がないか調べます。
原因が不明なまま本番サーバーを一斉に再起動したり、WAFを無効化したりすると、証拠を失ったり新たな問題を生む可能性があります。まずログを保全し、影響範囲と変更権限を確認してから安全な対応を検討しましょう。
手順6：再発したかを同じ条件で確認する
設定や処理を改善した後は、一度だけ正常画面が表示されたかだけでなく、以前失敗が集中していた時間帯や利用者の条件で再発していないかを確認します。断続的な障害は元から成功する時間が多いため、直後の一回の成功では改善の評価が難しいからです。
変更前後の監視履歴、応答時間、サーバー側の関連ログを比較します。再発が見つからなくても、監視で観測できなかった時間があるなら「完全に解決した」と断定せず、何を確認したかを記録してください。技術担当者・運用担当者の役割と連絡順についてはアラート設計と連絡順の記事も参考になります。
断続的な障害の再発を減らすために残す記録
時々落ちるサイトでは、一回の障害調査で原因が確定しないこともあります。それでも発生条件を残しておけば、次の再発時に同じ説明や確認作業を繰り返さずに済みます。記録するのは結果だけでなく、未確認の範囲も含めた事実です。
成功と失敗の両方を残す
失敗時のスクリーンショットやエラーログだけでなく、直前・直後の正常なチェックも残しましょう。例えば11時10分に503、11時15分に200、11時20分にタイムアウトという並びがあれば、常に停止していたわけではないことを観測結果として説明できます。
成功と失敗の切り替わりが特定の時間帯や特定サーバーに偏っているかは、複数回の再発記録で確認します。最初の失敗を削除して成功だけを残すと、短時間の問題が続いていたか判断しにくくなります。
調査したことと未確認のことを分ける
管理記録には「外部監視で503を取得」「該当時刻のアクセス数が増加」「データベースログは未確認」というように、確認済みの事実と未確認項目を分けて記載します。「サーバー負荷が原因」と断定できない段階なら「負荷との関係を調査中」と残します。
この区別は担当交代にも役立ちます。次の担当者が追加で見るべき項目を把握でき、同じ時刻の証拠を後から探す手間を減らせます。複数サイトの担当者や管理会社の情報整理は複数Webサイトを一元管理する方法にまとめています。
監視できなかった区間を正常扱いしない
定期チェックの間に起きた短い障害は観測できない場合があります。また監視基盤が稼働していない期間や、サイトを意図的に監視停止した期間は、結果が取得できません。データがない区間を自動的に「正常だった」とみなすことはできません。
一方、データがないだけでサイトが停止していたと断定することも不適切です。観測できた時間とできなかった時間を分けて記録し、必要ならサーバー側の詳細ログや利用者の情報で補うようにします。
エンリンクで断続的な障害を確認するときの使い方
エンリンクの公式機能一覧には、HTTP/HTTPSの定期監視、HTTPコードと応答時間の履歴、連続失敗による障害の可能性の記録、障害・復旧履歴、24時間・7日間の集計、平均・P95応答時間、直近24時間の推移グラフが案内されています。これらを使う場合も、取得された観測結果と、障害原因の確定は別として扱います。
サイト別の監視履歴から失敗前後の変化を探す
まず管理画面で注意が必要なサイトを確認し、対象サイトのHTTPコード・応答時間・判定理由の時系列履歴をたどります。失敗したチェックと、その直前・直後の成功を比較すると、断続的な状態を示す証拠を整理できます。
平均とP95、直近24時間の応答時間推移は、遅い時間帯の手掛かりとして役立つ可能性があります。ただし時間帯別に集約されたグラフと、個別のチェック1件は同じ粒度ではありません。気になる区間があれば個別履歴に戻り、失敗の種類を確認してください。
連続失敗の判定と短時間障害の記録を区別する
公式機能一覧では、一定回数の連続失敗によって障害の可能性を記録する仕組みが案内されています。これは一時的な失敗と継続異常を区別して確認するための情報であり、すべての短時間障害を必ずイベント化する保証ではありません。
単発失敗が履歴に残っていても障害イベントとして扱われない場合や、チェックの間に発生した停止を観測できない場合があります。監視の成功率をそのまま実際の停止時間と同一視せず、記録できた範囲を説明してください。
監視間隔は料金プランの範囲で確認する
2026年10月24日時点のエンリンク料金プランでは、無料プランは最大5サイトを登録でき、定期監視は1日2回です。有料プランでは15分・5分・1分という最短間隔が案内されています。ただし、設定間隔は検査時刻や障害検知までの時間の保証ではありません。
この記事の5分間隔のサンプルは説明用の仮定であり、すべてのエンリンク利用者の実行条件を示すものではありません。また複数地域からの同時監視、ブラウザー操作テスト、障害原因の自動特定をエンリンクが提供していることは、現行の公開機能説明から確認できません。利用する機能は公式機能一覧で確認してください。
保存された履歴から調査の出発点を作る
「朝9時にタイムアウトが集中」「変更後だけ503が発生」といった状況が見つかったら、その時刻のサーバー負荷や更新履歴を、権限を持つ担当者が調べます。外部監視のデータだけで原因を確定せず、サーバーのログや公式障害情報などと照合します。
自分が管理するWebサイトをまとめて登録し、HTTP監視結果や履歴を確認したい場合は、最大5サイトまで無料で使えるエンリンクから始められます。最初から「完全に障害を防止する」ことを期待するのではなく、再発時に何が観測されたか説明できる記録を蓄積することが重要です。
Webサイトが時々落ちるときによくある質問
断続的な障害は、正常に戻ったタイミングで原因を見失いやすい問題です。監視記録から分かることと、追加の検証が必要なことを分けて、よくある質問に回答します。
サイトが数分で復旧する場合は放置してもよいですか？
一時的に復旧しても、利用者が問い合わせ・応募・購入などを完了できなかった可能性があります。発生した時刻と影響を確認し、同じ時間帯に繰り返していないか調べてください。再発が続く場合は放置せず、担当者がログや運用変更履歴を確認することが重要です。
毎日決まった時間だけ落ちる場合の原因は何ですか？
定期バックアップやバッチ処理、アクセス集中、予定された作業などが候補です。ただし時間帯だけでは確定できません。実際のジョブ開始時刻、負荷指標、エラーログと、監視で失敗した時刻を揃えて調べます。
スマホだけ開けない場合もサーバー障害ですか？
一概には言えません。モバイル回線の経路、DNS、CDNの配信先、アクセス制限、ブラウザーの動作などが関係する可能性があります。同時刻に別回線・別端末・別地域から確認した結果を集め、共通する条件を探してください。
HTTPが200と表示されるなら問題はないのですか？
いいえ。200はHTTPリクエストの成功応答ですが、画面の表示内容やログイン・送信の成功までは保証しません。外部HTTP監視の成功と利用者の操作が正常に完了したことは別の確認が必要です。
5分間隔の死活監視で1分程度の停止は検知できますか？
検知できる場合もありますが、保証はできません。1分程度の停止が5分おきのチェックと重ならなければ、失敗した時刻を観測できないためです。短い障害の調査では、アクセスログや利用者の報告などの別の情報も確認してください。
監視で失敗した後、次が成功すれば誤検知ですか？
必ずしもそうではありません。短時間だけ実際に停止していた可能性があります。一方、監視拠点固有の通信経路で失敗した可能性もあるため、同じ時刻の別地点の観測やサーバーログと照合して判断します。
503とタイムアウトが交互に出る場合、原因は同じですか？
同じとは限りません。503はHTTPのエラー応答が返った記録、監視側のタイムアウトは規定時間内に応答を取得できなかった記録である場合があります。どの段階で失敗したかを区別して調べてください。特定の500系コードの修正方法だけに絞る前に、断続的な発生条件を確認します。
監視履歴に失敗が残っていないなら障害はなかったのですか？
そう断定できません。チェックの間に障害が発生して終わった場合や、監視地点以外の利用者だけで問題が起きた場合、履歴には失敗が現れない可能性があります。何を、どの時刻・地点・条件で監視していたかを確認してください。
原因が分からないとき、最初にサーバーを再起動してよいですか？
原因未確認の再起動は、調査に必要な記録を失ったり、影響を広げたりする可能性があります。まず監視結果、エラーログ、変更履歴、負荷指標を確認し、必要な場合は権限のある担当者が復旧手順と影響範囲を判断してください。
まとめ：時々落ちるWebサイトは「いつ・どこで・何が失敗したか」を残す
Webサイトが断続的に落ちる場合は、アクセス集中、定期ジョブ、データベースやアプリケーションの一時的な不調、デプロイ時の切り替え、CDN・DNS・WAFなどを原因候補として考えます。同じURLで成功と失敗が入れ替わる時刻を記録し、その前後の負荷・変更・通信経路の証拠と照合することで、調査対象を絞りやすくなります。
一度正常に戻ったことだけで障害を否定せず、チェック間に起きた短い停止や、一部の地域・利用者だけに起きた問題も考慮してください。監視履歴の失敗回数を実際の停止時間と同一視しないこと、監視地点固有の失敗をサイト全体の停止と断定しないことも重要です。
エンリンクは公開サイトのHTTP/HTTPS監視、応答時間、障害・復旧履歴などをまとめて確認するためのサービスです。5サイトまで無料でサイト監視を始めることができるため、まずは管理サイトの成功・失敗と応答時間を記録し、再発時の調査に役立つ情報を蓄積するところから始めましょう。
参考にした一次資料：Google Cloud「Create public uptime checks」、Google Cloud「Troubleshoot uptime checks」、Google SRE Workbook「Monitoring」、AWS Well-Architected「Monitor workload resources」、Microsoft Azure Well-Architected「Monitoring」、Cloudflare「Error 502 or 504」（最終確認：2026年10月24日）。
