スクリーンショットの問題

サイトがダウンします。アラートが届きます。慌ててサイトを確認すると、すでに復旧しています。何が原因だったのでしょうか?もう知るすべはありません。

スクリーンショットがなければ、デバッグは推測の連続になります。

500エラーだったのか?
リダイレクトループだったのか?
データベースのタイムアウトだったのか?
CSSの読み込み失敗だったのか?
JavaScriptのエラーだったのか?

スクリーンショットがあれば、これらの疑問に瞬時に答えが出ます。

Nova Uptimeのスクリーンショットの仕組み#

ドメインチェックが失敗すると、Nova Uptimeは自動的に以下をキャプチャします。

障害時のスクリーンショット: 不具合発生時のサイトの見た目
障害の詳細: ステータスコード、応答時間、エラーメッセージ
復旧時のスクリーンショット: 復旧した時点の見た目

すべてキャプチャされ、インシデントレポートに添付されます。

スクリーンショットからわかること

例1: 503 Service Unavailable#

スクリーンショットの内容:

503 Service Unavailable
The server is temporarily unable to handle the request

ひと目でわかること: サーバーが過負荷または再起動中。DNSや設定の問題ではない。

例2: リダイレクトループ#

スクリーンショットには、アドレスバーでURLが繰り返し変わっている様子や、読み込みが止まっている状態が映っています。

ひと目でわかること: リダイレクトルールの設定ミス。おそらく直近のデプロイ後の問題。

例3: 真っ白なページ (500エラー)#

スクリーンショットには、ほぼ真っ白なページにサーバーエラーのスタックトレースが表示されています。

ひと目でわかること: アプリケーションがクラッシュ。具体的なエラーはログを確認。

例4: データベース接続エラー#

スクリーンショットにデータベースのエラーメッセージが表示されています(エラーページが見える設定の場合)。

ひと目でわかること: データベースがダウンしているか到達不能。データベースサーバーの状態を確認。

インシデントレポート内のスクリーンショット

インシデントが発生すると、Nova Uptimeは以下を提供します。

タイムライン:
- 14:32 UTC: 最初の障害を検出
- 障害時のスクリーンショットを添付
- 14:47 UTC: 復旧を検出
- 復旧時のスクリーンショットを添付
分析:
- 継続時間: 15分
- エラー: 503 Service Unavailable
- 視覚的証拠: スクリーンショットに「Server restarting」と表示
コンテキスト:
- 障害発生前の応答時間: 平均200ms
- 障害中の応答時間: タイムアウト (60秒以上)
- 復旧後の応答時間: 平均195ms

これらからわかること:

何らかの負荷が発生(60秒のタイムアウトまで急増)
サーバーが自動的に再起動
サーバーは復旧し、現在は正常に稼働

メールアラート内のスクリーンショット

Nova Uptimeは障害時のスクリーンショットをアラートメールに直接添付します。

🚨 DOWNTIME ALERT

Domain: mysite.com
Status: DOWN (503 Service Unavailable)
Duration: 12 minutes

[障害時のスクリーンショットを添付]

対応:
- サーバーログで「Server restarting」エラーを確認
- データベース接続を確認
- 直近のデプロイを確認

チームはNova Uptimeのダッシュボードを開かなくても診断できます。

根本原因分析のためのスクリーンショット

スクリーンショットは「なぜ失敗したのか?」という問いに答えてくれます。

シナリオ1: デプロイがサイトを壊した

デプロイ前のサイトのスクリーンショットがある
デプロイ後のスクリーンショットにはエラーページが映っている
結論: 今すぐロールバックが必要
対応: 直近のコミットをgit revert

シナリオ2: データベースに到達不能

スクリーンショットに「Connection refused」エラーが表示
結論: データベースサーバーがダウンしているかネットワーク障害
対応: データベースサーバーの状態とネットワーク接続を確認

シナリオ3: SSL証明書の期限切れ

スクリーンショットにSSL証明書エラーが表示
結論: 証明書が期限切れで更新が必要
対応: 証明書を更新(手動または自動)

シナリオ4: リダイレクトループ

スクリーンショットにブラウザが再読み込みを繰り返している様子が映る
結論: リダイレクト設定のミス (HTTP → HTTPS → HTTP → ...)
対応: nginx/Apacheの設定でリダイレクトルールを確認

復旧時のスクリーンショット

サイトが復旧すると、Nova Uptimeは復旧時のスクリーンショットをキャプチャします。

✅ RECOVERY

Domain: mysite.com
Status: UP (200 OK)
復旧時のスクリーンショット: [サイトがホームページを正常に表示]

ダウンタイムのまとめ:
- 開始: 14:32 UTC
- 終了: 14:47 UTC
- 継続時間: 15分
- 根本原因: デプロイ中のサーバー再起動
- 応答時間: 通常に復帰 (200ms)

これによって以下が確認できます。

サイトが本当に復旧している(エラーで応答しているだけではない)
サイトが応答可能 (HTTP 200だけでなくスクリーンショットが証明)
正常な機能が戻っている

モバイル版スクリーンショットについて

ウェブサイトはモバイルとデスクトップで見え方が異なります。Nova Uptimeは以下をキャプチャします。

デスクトップ表示: 1024x768 (設定変更可能)
モバイル表示: 375x667 (オプション)

モバイルファーストのサイトであれば、モバイルのスクリーンショットも忘れずに確認しましょう。

スクリーンショットのプライバシーへの配慮

スクリーンショットには次の情報が含まれる可能性があります。

ユーザー向けのエラーメッセージ
データベースのエラー詳細
機密情報

ベストプラクティス:

エラーページに機密データを残さない
公開向けには汎用的なエラーメッセージを使う
利用可能であればスクリーンショットの暗号化を有効にする
ダッシュボードへのアクセスをチーム内に限定する

ステータスページでのスクリーンショット活用

障害時のスクリーンショットは顧客向けに共有することもできます。

顧客への連絡例:

本日 14:32-14:47 UTC に障害が発生しました。
[エラーメッセージを表示したスクリーンショット]
根本原因: デプロイ中のサーバー再起動
対処: [復旧のために行った内容]

透明性は信頼を築きます。スクリーンショットは誠実さの証拠になります。

自動スクリーンショットキャプチャ

Nova Uptimeは以下のタイミングで自動的にスクリーンショットを取得します。

障害発生時ごと: ダウンアラート → スクリーンショット取得
復旧時: 復旧アラート → スクリーンショット取得
スケジュール実行: 有効化していれば毎日のスクリーンショット(サイトが稼働中であることの証拠)

設定 → スクリーンショットオプションから設定できます。

手動でのスクリーンショット要求

監視以外でスクリーンショットが必要になることもあります。

Nova Uptimeのダッシュボードでドメインをクリック
「Request Screenshot」ボタンを押す
サイトの現在の状態が即座に表示される
過去の障害時スクリーンショットと比較する

スクリーンショット vs ログ#

スクリーンショットは ユーザーに見えているもの を映します。ログは サーバーが認識していること を記録します。

両者が食い違うことがあります。

ログの内容: 「リクエスト処理成功 (200 OK)」
スクリーンショットの内容: 「Database connection failed」というエラーメッセージ

スクリーンショットは、ログが主張する内容と実際に起きていることのギャップを捉えます。

スクリーンショットの限界

スクリーンショットでは以下を捕捉できません。

JavaScriptエラー(画面に表示されない場合)
APIの応答遅延(ページが読み込めている場合)
サブリソースのネットワークタイムアウト
クライアント側の問題(ブラウザのクラッシュ)

回避策: 高度なシナリオには、ブラウザベースの合成監視を併用します。

まとめ

スクリーンショットは次の問いに即座に答えてくれます。

失敗した瞬間に何が起きていたのか?
復旧までどのくらいかかったのか?
サイトは本当に完全復旧しているのか?
視覚的な証拠は何か?

今すぐNova Uptimeで自動スクリーンショットを有効にしましょう: Nova Uptimeのドメイン設定からスクリーンショットキャプチャをオンに切り替えるだけです。すべてのプランで利用可能です。🚀

障害サービスのスクリーンショット証拠：アップタイム問題のデバッグ