HTTP応答障害を検知する監視設定ガイド｜ステータスコード別アラート実践

サイトが「落ちている」とき、クライアントよりも先に検知できているでしょうか。HTTP応答障害の検知は、死活監視の中でも最も基本的かつ重要な機能です。しかし「何をもって障害と判定するか」「どのステータスコードでアラートを出すか」の設計が雑だと、誤検知が増えたり、逆に重大な障害を見逃したりします。

このガイドでは、HTTP応答障害の正確な検知方法——ステータスコード別の判定ロジック、アラート設定のベストプラクティス、Miterlでの実装手順——を解説します。

HTTPステータスコードと障害判定

HTTPステータスコードは3桁の数字で、サーバーがリクエストをどのように処理したかを示します。

監視ツールが「DOWN」と判定する条件

Miterl では以下の条件でステータスを「DOWN」に切り替え、アラートを発報します。

• サーバーから5xxレスポンスが返った場合
• 設定した時間内に応答がなかった場合（タイムアウト）
• 接続自体が拒否された場合（Connection refused）
• DNSの名前解決に失敗した場合

ステータスコード別の障害判定ポリシー

5xx系：サーバーエラー（即時アラート対象）

5xx系はサーバー側に問題が発生していることを示すため、即時アラートの対象です。

制作会社の案件では、WordPress の PHP エラーが 500 を引き起こすケースが最も多く見られます。プラグイン更新後や大量ページ生成処理の直後は特に注意が必要です。

4xx系：クライアントエラー（状況に応じて判断）

4xx系は「リクエストに問題がある」ことを示しますが、サイト全体の障害ではないケースも多いです。

重要: 監視ツールはブラウザではないため、Basic認証がかかっているURLをそのまま監視すると 401 が返ってきます。認証情報をリクエストヘッダに含めて設定する必要があります。

タイムアウト：応答なし（即時アラート対象）

タイムアウトはステータスコードが返らない状態です。以下のケースが該当します。

• サーバーが起動していない（ホスティング障害）
• ファイアウォールがリクエストをブロックしている
• ネットワーク経路の問題
• サーバーが過負荷で接続キューが溢れている

タイムアウトの閾値は「サイトの通常レスポンス時間 × 3〜5倍」を目安に設定します。通常1秒以内のサイトであれば、5〜10秒でタイムアウトとする設定が一般的です。

Miterlでの実装手順

基本的なHTTPモニターの作成

# HTTPモニターを作成（5xxとタイムアウトで自動的にDOWN判定）
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/",
    "name": "example.com - コーポレートサイト",
    "type": "http",
    "interval_seconds": 60,
    "alert_contact_ids": [1, 2]
  }'

interval_seconds: 60 は1分ごとに確認する設定です。重要なサイトは60秒、そうでないサイトは180秒（3分）が一般的な設定です。

認証が必要なページの監視

管理画面や会員ページを監視する場合は、リクエストヘッダに認証情報を含めます。

# Basic認証が必要なURLの監視設定
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/admin/",
    "name": "example.com - 管理画面",
    "type": "http",
    "interval_seconds": 180,
    "request_headers": {
      "Authorization": "Basic dXNlcjpwYXNzd29yZA=="
    },
    "alert_contact_ids": [1]
  }'

モニターの状態確認

# 現在のステータスを確認
curl -s "https://miterl.com/api/v1/monitors/1" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '{name: .name, status: .status, uptime_30d: .uptime_30d}'
# 出力例: {"name": "example.com", "status": "up", "uptime_30d": 99.97}

誤検知を減らすアラート設定

リトライ回数の設定

HTTP障害の多くは瞬間的なもの（ネットワーク経路の一時的な揺れ、サーバーの短期スパイク）です。1回の異常ですぐにアラートを出すと誤検知が増えます。Miterl ではデフォルトで確認回数を設定でき、複数回連続して異常が確認されてからアラートを発報する設定が可能です。

推奨設定:

• コーポレートサイト: 2回連続でDOWNを確認したらアラート
• EC・予約システム: 即時アラート（1回でDOWN確認）

Quiet hours（深夜アラートの抑制）

深夜の軽微な一時的障害（2〜3分で自動復旧するもの）に毎回起こされると、担当者のアラート疲れにつながります。重要度が低いサイトは深夜時間帯のアラートを抑制する設定を入れることを検討してください。

アラート疲れの防止策全般については「アラート疲れを防ぐ監視設定」でまとめています。

HTTP応答障害の検知から復旧までのフロー

[Miterl が5xxまたはタイムアウトを検知]
        ↓
[1分後に再確認（リトライ）]
        ↓
[2回連続でDOWN → アラート発報（Slack + メール）]
        ↓
[担当者が受信 → 障害内容を確認]
        ↓
[原因特定: 5xxならサーバーログ確認、タイムアウトならサーバー起動確認]
        ↓
[復旧対応（PHPエラー修正・サービス再起動など）]
        ↓
[Miterl が2xxを確認 → UP アラート発報（復旧通知）]
        ↓
[クライアントへ報告（第一報・経緯説明）]

アラートを受け取ってから復旧までの全フローは「Webサイト障害対応の手順書：制作会社向けインシデントレスポンスガイド」で詳しく解説しています。

複数URLを一括監視する

制作会社では複数のクライアントサイトを同時に管理します。APIを使うと一括で監視状態を把握できます。

# 全モニターの現在ステータスを一覧取得
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq -r '.data[] | "\(.status) | \(.name)"'
# 出力例:
# up | 株式会社A - コーポレートサイト
# down | 株式会社B - ECサイト  ← 障害中
# up | 株式会社C - 予約システム

DOWN 状態のサイトだけを抽出するフィルタリングも可能です。

# DOWNのモニターだけを取得
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq -r '.data[] | select(.status == "down") | "\(.name): \(.last_checked_at)"'

よくあるHTTP応答障害のパターンと原因

まとめ

HTTP応答障害の検知は「何をもって障害と判定するか」の定義から始まります。

• 5xxとタイムアウトは即時アラート対象
• 4xxは状況に応じて判断（認証エラーは監視設定の見直し）
• 誤検知を減らすにはリトライ設定と quiet hours を活用する
• 複数サイトはAPIで一括監視して漏れをなくす

HTTP応答監視でサイトの「生死」は判定できますが、「遅くなっている」は判定できません。レスポンスタイムの劣化を早期に検知する方法は「レスポンスタイム監視とは？サイト表示速度の低下を早期発見する方法」で解説しています。SSL証明書の期限切れも「HTTPSが返らなくなる」という形でHTTP監視に引っかかりますが、事前に防ぐには「SSL証明書の期限切れ事故を防ぐ！自動監視で安全なサイト運用を」で専用の期限監視を設定しておくのが確実です。

Miterlで今すぐ試したい方は無料プランで登録してください。詳しい機能はドキュメントで確認できます。監視の設定から運用ノウハウまでの事例はユースケースページをご覧ください。導入前の疑問はよくある質問もあわせてご確認ください。