WordPressサイトの障害を、読者からの連絡で初めて知る状態は避けたいものです。Cloudflare Notificationsを設定すると、Cloudflare側のインシデント、メンテナンス、HTTP DDoS攻撃、Universal SSL証明書の問題など、利用中のプランと製品で提供される変化をメールなどで受け取れます。
ただし、通知はWordPressの死活監視やエラーログの代わりではありません。「通知が来た＝自サイトの原因が確定」「通知がない＝正常」とは判断せず、発生時刻と影響範囲を別の証拠で照合します。
最初からすべての通知を有効にせず、誰が受け取り、何分以内に何を確認するかを決めてから追加してください。受信後の担当が曖昧な通知は、件数が増えるほど見落とされやすくなります。
先に結論｜無料プランはメール通知から始める
2026年8月21日時点のCloudflare公式Notifications資料では、Notificationsは全プランで利用できます。Freeプランではメール、Pro以上ではWebhook、Business以上ではPagerDutyを利用できます。アカウント内に上位プランのzoneがある場合、配信先の利用範囲がその上位プランを基準に広がる場合があります。
- 最初はIncident Alerts、Maintenance Notification、Universal SSL Alertを確認する
- HTTP DDoS Attack Alertが表示される場合は追加する
- 受信先は個人だけでなく、引き継げる共有アドレスも検討する
- ポリシー作成後にテスト通知を送り、件名・送信元・迷惑メール判定まで確認する
- 通知を受けたらStatusページ、対象URL、Ray ID、ログを照合する
Cloudflareの通知サービスが対象にするのは、Cloudflareでプロキシされているドメインです。DNSレコードがDNS onlyのまま、または対象zoneを取り違えている場合は、期待した通知設計になりません。
Notificationsとログ・Statusページの違い
| 確認方法 | 役割 | 向く判断 | 限界 |
|---|---|---|---|
| Notifications | 条件に合う変化を能動的に知らせる | 障害や証明書問題へ早く気づく | WordPressの死活監視ではない |
| Statusページ | Cloudflare全体・地域・製品の状態を公開する | 広域障害かを切り分ける | 自分のzone固有問題をすべて示さない |
| Audit Logs | Cloudflare設定への操作を残す | 誰が何を変更したか | 個々のWeb通信は分からない |
| Log Explorer | 有効化後の実HTTP通信を検索する | URL、Ray ID、edge・origin応答の照合 | 通知や設定変更の履歴ではない |
| Security Events | WAFなどの検知・対処を記録する | ブロックやChallengeの理由 | 正常通信や全障害を網羅しない |
通知が来たら、Cloudflare全体の障害はCloudflare障害の確認手順、直前の設定変更はCloudflare Audit Logsの見方、WAFの対処はCloudflare Security Eventsの見方へ分けて確認します。通知は調査開始の合図であり、原因を自動確定する証拠ではありません。
利用できる通知と配信先を確認する
通知の種類はプランだけでなく、契約している製品や対象zoneによって変わります。公式の利用可能な通知一覧には、全プラン向けの通知と、Enterpriseや個別製品向けの通知が混在しています。記事の一覧をそのまま有効化できると思わず、実際のダッシュボードで「Add」後に表示される候補を基準にしてください。
| 配信先 | 基本的な利用条件 | 運用上の注意 |
|---|---|---|
| 全プラン | 迷惑メール、受信ルール、退職・担当変更を確認 | |
| Webhook | 少なくとも1つのPro zoneがあるアカウント | secret検証と受信先の保護が必要 |
| PagerDuty | Business以上が基本 | 夜間を含む当番設計が必要 |
権限も確認します。ダッシュボードで通知を作るには、Super AdministratorまたはAdministrator権限が案内されています。APIで扱う場合はNotificationsのReadまたはWrite権限を持つAPI tokenが必要です。通知設定だけのために、日常利用者へ広すぎる権限を渡さないでください。
作成前に決める6項目
- 対象のCloudflareアカウントとzone
- 検知したい出来事と優先度
- 平日・夜間・休日の受信担当
- 第一報から確認開始までの目安
- 確認するStatusページ、URL、ログ
- ミュートや削除を判断できる責任者
通知名は「本番 example.com Universal SSL」「全zone Cloudflare Incident」のように、環境・対象・通知種類が一目で分かる形にします。「テスト」「通知1」では、数か月後に止めてよいポリシーか判断できません。メール本文を転送するだけでなく、受信後の確認手順を運用メモへ残します。
通知ポリシーを作成してテストする
- Cloudflareダッシュボードへログインする
- 左側の「Notifications」を開く
- 「Add」を選ぶ
- 利用可能な通知種類から一つ選ぶ
- 環境と対象が分かる通知名を付ける
- Emailなどの配信先を選ぶ
- 表示される場合はzone、サービス、影響度などの条件を指定する
- 「Create」で保存し、Enabledになっていることを確認する
- 作成したポリシーの「Test」で模擬通知を送り、受信を確認する
Cloudflare公式の作成手順では、新しいポリシーは有効な状態で作成され、既存ポリシーはEnabledの切り替えで停止できます。Testは偽のデータを含む通知です。テスト本文を実障害と誤認しないよう、実施時刻を受信者へ先に共有してください。
WordPress運用で優先したい通知
| 優先度 | 通知 | 気づけること | 受信後の初動 |
|---|---|---|---|
| 1 | Incident Alerts | Cloudflareインシデントの作成・更新・解消 | 影響サービス、地域、時刻をStatusページで照合 |
| 2 | Maintenance Notification | データセンター保守の予定・変更・中止 | 対象PoPと予定時間を確認 |
| 3 | Universal SSL Alert | 検証、発行、更新、期限の問題 | 失敗状態なら証明書とDNSを確認 |
| 4 | HTTP DDoS Attack Alert | Cloudflareが緩和した一定規模のHTTP攻撃 | 対象zone、時間、サイト症状を確認 |
| 5 | Security Insightsなど | 利用環境で提供される改善情報 | 緊急度を分けて定期確認 |
Incident Alertsは影響度やコンポーネント、Maintenance NotificationはPoPや状態で絞れる場合があります。まず広めに一つ作って受信量を観察し、必要な条件だけを追加します。フィルター条件に一致しなかった段階のインシデントは、後から影響度が変わっても過去分が遡って届くとは限らないため、狭くしすぎないことも大切です。
HTTP DDoS Attack Alertは、CloudflareがWAF/CDNで毎秒100リクエストを超えるHTTP攻撃を緩和した際の通知として案内されています。通知自体に「対処済み」とあっても、WordPressのログイン、フォーム、購入など主要機能への影響は別に確認します。SSL通知でedge証明書の発行・更新失敗が示された場合はEdge CertificatesとDNSを確認し、origin証明書の期限・SAN・証明書チェーンで526が出る場合はCloudflare Error 526の直し方へ分けて進みます。
通知を受け取った直後の確認順
- 通知名、受信時刻、対象account・zoneを保存する
- 通知の種類、状態、影響度、対象サービスを読む
- Cloudflare Statusページの同じ時刻とサービスを確認する
- WordPressのトップ、記事、ログイン、フォームを別回線から確認する
- エラー画面があればHTTP状態、完全URL、Cloudflare Ray IDの確認方法に沿ってRay IDを保存する
- 実通信が必要ならCloudflare Log Explorerの使い方で短い時間帯を検索する
- 誰が・何を・次回いつ確認するかを共有する
インシデント通知には開始、更新、解消が続く場合があります。最初のメールだけを見て完了にせず、状態が変わるたびに時刻を並べます。Cloudflare側が解消になっても自サイトだけ異常が残るなら、origin、WordPress、キャッシュ、直前の設定変更へ調査を切り替えます。
ミュート・無効化・削除の使い分け
| 操作 | 向く場面 | 確認事項 |
|---|---|---|
| Mute | 計画作業中など一時的に止めたい | 1時間、12時間、24時間、任意期間と解除時刻 |
| Enabledをオフ | 設計を見直すまで停止したい | 再開責任者と期限 |
| Delete | 重複・廃止が確定した | 他の受信者や手順から参照されていないか |
ミュート中のアラートは配信されませんが、Notification Historyにはsilencedとして残ります。保守終了後はHistoryを確認し、重要な変化が隠れていなかったかを確かめます。
通知が多いという理由だけで、重要なポリシーを無期限に停止しないでください。対象zone、影響度、コンポーネント、配信先を調整し、停止が必要なら再開日時と担当者を同時に記録します。
Webhookを使う場合の安全設定
Webhookはチャットや監視基盤へ通知を連携するときに便利ですが、受信URLを公開しただけでは安全ではありません。Cloudflare公式のWebhook設定手順では、NotificationsのDestinationsからWebhookを作成し、名前、URL、secretを設定してSave and Testします。
- 推測されにくいsecretを設定する
- 受信側でcf-webhook-authヘッダーの存在と一致を検証する
- 一致しない要求は処理しない
- secretを記事、画面共有、公開リポジトリへ載せない
- CloudflareのIP範囲を許可する場合は変更可能性を考慮する
- 本物の通知でも項目が欠ける可能性を前提に受信処理を作る
Webhook通知を、そのままDNS変更やサーバー再起動などの自動復旧へ直結しないでください。偽装、重複、遅延、項目欠落を考え、まず記録と担当者への通知に限定します。
通知が届かないときの確認項目
- 正しいCloudflareアカウントとzoneを選んだか
- 対象ドメインがCloudflareでプロキシされているか
- ポリシーがEnabledになっているか
- 通知種類と配信先がプラン・製品で利用可能か
- 受信者のアドレスに誤りがないか
- 迷惑メール、隔離、転送、受信拒否ルールに入っていないか
- Test通知は届くか
- zone、影響度、コンポーネントの条件を狭めすぎていないか
- Mute期間中ではないか
- Notification Historyにsilencedまたは配信記録があるか
- 編集権限のあるアカウントで確認しているか
Testが届かない場合は配信経路、Testは届くのに実通知がない場合は条件・対象・イベント有無を優先して調べます。実際に障害を起こして通知を試す必要はありません。
よくある失敗
- 利用可能一覧を確認せず、Enterprise向け通知を探し続ける
- 通知名が曖昧で、本番・検証環境を取り違える
- 個人メールだけに送り、担当変更後も放置する
- 作成後にTestを実行しない
- 通知を死活監視や原因確定の証拠として扱う
- 条件を狭めすぎて重要な更新を受け取れない
- ミュート解除の日時を決めない
- Webhook secretを検証しない
- DDoS通知を見て、必要のない設定変更を重ねる
- 解消通知の後にWordPressの主要機能を再確認しない
よくある質問
Freeプランでも使えますか？
はい。Notifications自体とメール配信は全プラン向けです。ただし、個々の通知種類は製品・プランで異なります。ダッシュボードのAdd画面に表示される候補を確認してください。
通知がなければCloudflareは正常ですか？
断定できません。ポリシー条件に合わない問題、自分のzoneだけの設定、originやWordPressの障害などは通知されないことがあります。Statusページと実際のサイト症状を照合します。
メールとWebhookはどちらを選びますか？
少人数運用はメールから始めるのが簡単です。複数担当、当番、記録の自動集約が必要ならWebhookを検討します。Webhookはsecret検証と受信側の保守ができることが前提です。
まとめ
- Cloudflare Notificationsは全プランで利用でき、Freeはメールから始められる
- 通知種類はプラン・製品で異なるため、ダッシュボードの利用可能候補を基準にする
- Incident、Maintenance、Universal SSL、HTTP DDoSを優先して検討する
- 作成後はTestを送り、受信者・迷惑メール・運用手順まで確認する
- 通知は調査開始の合図であり、Status、Ray ID、ログと照合して原因を判断する
- ミュートには解除時刻、Webhookにはsecret検証を必ず用意する
まず重要な通知を一つ作り、テスト受信から始めてください。受信したときの確認順まで決めておけば、慌ててCloudflareやWordPressの設定を変えるのではなく、証拠を残しながら安全に切り分けられます。