先に結論
503は『現在リクエストを処理できない』一時状態です。予定保守か障害かを分け、到達率・容量・ヘルスチェック・依存先を同じ時刻で確認します。
最初の5分で「誰が503を返したか」を特定
- URL、発生時刻、503画面、レスポンスヘッダー、リクエストIDを保存する。
- 予定保守、デプロイ、スケール変更、WAF・CDN設定変更の有無を確認する。
- CDN/LB/アプリの各層で、503の返却数と健全性を確認する。
- CPUだけでなく、メモリ、worker、DB接続、キュー、ファイル記述子、I/Oを見る。
- DB、認証、キャッシュ、外部APIなど共通依存先の遅延・失敗を確認する。
結論：予定保守なら復旧予定と
Retry-After を示します。障害なら、過負荷を生む入口を抑え、正常系を残したまま詰まっている資源・依存先を特定します。503の発生パターンで原因を絞る
| 観測 | 優先候補 | 次の確認 |
|---|---|---|
| 全URL・全ノード | 共通依存先・保守 | DB、認証、設定、保守フラグ |
| 一部ノードだけ | ヘルスチェック・版差 | 対象ノード、デプロイ版、起動ログ |
| 負荷上昇と一致 | 容量・キュー枯渇 | 同時実行、接続pool、待ち行列 |
| 管理画面だけ | 認証・DB・プラグイン | 該当パスと依存先のログ |
| CDN/LBだけで503 | 上流の健全性なし | origin pool、health check、到達性 |
| 502/504も混在 | gateway・上流 | 502/504の時系列を確認 |
復旧は負荷を増やさない順序で
- 自動リトライ、クローラー、重いバッチなど急増要因を特定し、必要なら限定的に抑える。
- 健全なノード・リージョンを残し、異常ノードだけをLBから外す。
- キュー、DB接続、worker、メモリのどこが上限かを確認する。
- 直前変更と再現条件が一致する場合、影響範囲を限定して切り戻す。
- 復旧後も到達率、p95応答時間、503率、キュー長を監視して再発を確認する。
予定保守は検索エンジンと利用者へ一時状態を伝える
MDNは503を一時的な状態に使い、可能なら復旧見込みを Retry-After で示すよう案内しています。保守画面そのものが200や恒久リダイレクトを返していないか確認し、状態に合わない長期キャッシュを避けます。
避ける操作
- 利用者・ジョブ側で待ち時間のない無制限リトライを行う。
- 原因未確認のまま全ノードを同時再起動し、健全系も失う。
- 503を200へ書き換え、障害状態を監視・検索エンジンから隠す。
- 容量不足を解消せずタイムアウトだけを延ばし、待ち行列を増やす。
公式情報
WORDPRESS / 復旧後の判断
同じ運用を続けるかは、復旧後に分けて判断
障害中に移転を始めると、原因と移行差分が混ざります。まず復旧と証拠保存を優先し、その後に停止損失・復旧工数・移転費を同じ条件で比較します。
移転比較が近い売上・問い合わせへの影響があり、同種障害が反復。復元や保守の負担が大きく、30〜90日内に移転を判断したい。
まだ移転しない単発の設定・プラグイン原因で復旧済み。正常なバックアップと復元手順があり、停止損失も小さい。
先に確定する月間訪問、停止1時間の損失、現行費用、復旧工数、容量・帯域、移転期限をそろえる。
よくある質問
503は一時的なら放置してよいですか？
いいえ。503は一時的な利用不能を表しますが、保守なのか過負荷・容量不足・依存先障害なのかを確認します。予定保守なら復旧見込みとRetry-Afterを示します。
リロードを繰り返せば復旧しますか？
過負荷時の連打や無制限リトライは負荷を増やします。利用者側は待ち、運営側は到達率、キュー、接続数、ヘルスチェックと依存先を確認します。
502・504との違いは？
503は応答したサーバーが現在処理できない状態、502/504はgatewayが上流から有効な応答を得られない・期限内に得られない状態を一般に示します。どの層が返したかをヘッダーとログで確定します。