cloudflare down today の確認方法と status page の見方ガイド
「cloudflare down today なのか、自分の環境だけの問題なのか」を切り分けるには、公式の Cloudflare Status ページの見方を知っておくことが重要です。2025-12-05 時点で提供されているステータスページとAPI、通知機能の特徴を押さえておけば、世界的な障害なのか、自分のサイト固有の問題なのかを素早く判断しやすくなります。ここでは、初めての人でも迷わないように、Cloudflare Status ページの基本構造とチェック手順をわかりやすく解説します。
Cloudflare Status ページの基本構造
トップの「Overall Status」とインシデント一覧
Cloudflare Status（cloudflarestatus.com）は、「サービス全体の状態」と「個別コンポーネントの状態」「インシデント履歴」をまとめて公開している公式ページです。ページ上部には Overall Status（Overall Cloudflare Status）が表示され、”All Systems Operational” なら全システム正常、”Partial Outage” や “Major Outage” なら何らかの障害が進行中であることを示します。
その下には現在進行中のインシデント（Incidents）やスケジュールメンテナンス、コンポーネント一覧へのリンクが並び、どの製品・リージョンが影響を受けているかを掘り下げて確認できます。
| エリア | 表示される内容 | cloudflare down today の判断材料 |
|---|---|---|
| Overall Status | 全システムの総合ステータス | 「Major Outage」などなら広範囲な障害の可能性が高い |
| Incidents | 現在進行中・過去の障害一覧 | Cloudflare が公式に認識している障害かどうかを確認できる |
| Scheduled Maintenance | 計画メンテナンス情報 | アクセス不具合がメンテナンス由来かどうかを切り分けられる |
| Components | DNS・Network・Dashboardなどの個別コンポーネントの状態 | 自分が使っている機能に限定して状態を見ることができる |
- 要点: トップの Overall Status で、まず「大きな障害かどうか」をざっくり確認する
- 要点: そのうえで Incidents や Components を見て、自分の利用サービスに関係があるかを絞り込む
- 要点: 計画メンテナンス情報も確認し、「障害なのかメンテナンスなのか」を切り分ける
コンポーネント一覧で「どこが落ちているか」を見る
DNS・Network・Dashboard などの状態を細かくチェック
Components 一覧では、Cloudflare が提供する DNS、Network、WAF、Workers、Dashboard などのコンポーネントごとに “Operational”（正常）や “Degraded Performance”（性能低下）などの状態が表示されます。
たとえば「DNS」が障害状態なら、多くのドメインで名前解決ができず、Webサイトに到達できなくなる可能性があります。一方「Dashboard」だけが不調なら、ダッシュボード画面の操作に影響はあるものの、エンドユーザーから見たWebサイトは正常というケースもありえます。
| コンポーネント例 | 状態表示の例 | 利用者への影響イメージ |
|---|---|---|
| DNS | Major Outage | Cloudflare DNSに依存する多くのサイトにアクセスできなくなる可能性 |
| Network | Partial Outage | 特定リージョンやルートで遅延・エラーが発生 |
| Dashboard / API | Degraded Performance | 管理画面やAPIレスポンスが遅い／一時的にエラー |
| Zero Trust / WAF など | Identified / Monitoring | セキュリティ機能の一部が不安定な可能性 |
- 要点: 「どのコンポーネントに問題があるか」で、影響範囲と緊急度が変わる
- 要点: 自分のサービスが何を使っているか（DNSだけか、WAFもか）を把握しておくと判断しやすい
- 要点: Incident の詳細と Components をセットで確認すると理解が深まる
インシデント詳細ページの読み方
タイムラインとステータス遷移をチェックする
各インシデントをクリックすると、発生時刻・影響範囲・原因・対応状況などをまとめた詳細ページが表示されます。そこでは “Investigating”（調査中）、”Identified”（原因特定）、”Monitoring”（修正後の監視中）、”Resolved”（解決済み）といったステータス遷移と、タイムライン形式の更新履歴が確認できます。
自分のサービスで障害が起きている時間帯と、Cloudflare側のインシデント発生時刻を照らし合わせることで、「本当にCloudflare障害が原因なのか」「すでにResolvedになっているのに影響が続いているのか」などを判断する助けになります。
| ステータス | 意味 | 利用者側の解釈 |
|---|---|---|
| Investigating | 障害を認識し、原因調査中 | 影響が拡大する可能性もあるため注意深くモニタリング |
| Identified | 原因を特定し、対策を実施中 | 今後の更新（Mitigated / Resolved）も追う |
| Monitoring | 修正を適用し、状況を監視中 | 多くの影響は改善しているはずだが、一部で遅れが残ることも |
| Resolved | 障害対応完了と判断 | それでも問題が続く場合はキャッシュやオリジンサーバーの問題を疑う |
- 要点: ステータスの段階を見れば、障害の「今どのフェーズか」が分かる
- 要点: Resolved でもローカルキャッシュやオリジン負荷で問題が続くケースがある
- 要点: 自サービスのログやアラートと時刻を合わせて読むと原因の切り分けに役立つ
Status API・通知機能でより詳細に追跡する
Incident Alert と API を活用する方法
Cloudflare はステータスページに加えて、Status API と Incident Alert（インシデント通知）機能も提供しています。Status API を利用すると、コンポーネント状態やインシデント情報をJSON形式で取得し、自社の監視システムやダッシュボードに組み込むことができます。
一方、Incident Alert は Cloudflare ダッシュボードから数クリックで設定できるメール／Webhook／PagerDuty 通知で、特定プロダクトの障害が発生したタイミングで自動的にアラートを飛ばすことができます。
| 手段 | 特徴 | おすすめの使い方 |
|---|---|---|
| Status ページ | ブラウザから誰でも見られる | 手動での状況確認・障害時の一次情報源として |
| Status API | JSONでステータス情報を取得可能 | 監視ツールや社内ポータルへの埋め込みに |
| Incident Alert | メールやWebhookでインシデントを自動通知 | 運用チームへの即時共有や自動エスカレーションに |
- 要点: 手動チェックだけでなく、APIやアラート設定で自動化しておくと安心
- 要点: 重要度の高いサービスほど、Incident Alert の設定を推奨
- 要点: 自社の監視と Cloudflare Status を組み合わせることで、障害検知の精度が上がる
