Cloudflare Radarの新しいトップは、障害と通信量の地図になった ── アクセスが急に減った日、原因が自社の外にあるかを確かめる13項目（2026年10月時点）

目次

1. 01 何が起きたか — Cloudflare Radarのトップが、障害と通信量の地図になった
   1. Cloudflare Blogが、Radarの作り直しを書いた
   2. 新しいトップは、地図から始まる
   3. この記事が読んだもの、読めなかったもの
2. 02 なぜ・背景 — Radarが見せるのは、Cloudflareの網で見えた範囲である
   1. 「インターネット全体」ではなく、Cloudflareの網を通ったもの
   2. HTTPの画面とNetFlowsは、数えているものが違う
   3. 値は、元の件数ではない
   4. 障害には、場所・ネットワーク・種類・原因が付く
   5. アクセスが減る理由は、サイトの外だけではない
3. 03 用語 — 読み違えやすい言葉を先にそろえる
   1. ASN（エーエスエヌ）
   2. 正規化（min-max）
   3. UTC・日本時間・米国太平洋時間
   4. 障害（outage）と、通信量の異常（traffic anomaly）
4. 04 型別 — 自社がどれに当たり、何を、どの順で確かめるか
   1. 🅰 型A — ログインや会員登録、予約の画面を持つサイト
   2. 🅱 型B — 記事や紹介のページが中心で、検索から来る割合が高いサイト
   3. 🅲 型C — すでにCloudflareを使っているサイト
   4. 🅳 型D — Cloudflareを使っていないサイト（当サイトもこの型）
   5. 手順1 — 減った時間帯を、日本時間で決める
   6. 手順2 — 同じ曜日の、前の週と前々週と並べる
   7. 手順3 — 自社の側が、表示できていたかを確かめる
   8. 手順4 — RadarのOutage Centerで、期間を合わせて見る
   9. 手順5 — 通信量のグラフは、形だけを見る
   10. 手順6 — Googleの側を確かめる
   11. 手順7 — 結果を3つに分けて書く
   12. 公式が書いていないこと・確かめていないこと
5. 05 自分のサイトで確認するチェックリスト
6. 06 代替・他の選択肢 — Radar以外で、同じことを確かめる方法
   1. 通知を受け取る — Radar Alerts
   2. 契約先のステータスのページを、先にブックマークする
   3. 外から、自社のページを定期的に開く
   4. Search Consoleの数字は、見方を先に決めておく
   5. Radarの数字を、自社の報告に載せるとき
7. 07 当サイトで確かめたこと
   1. 当サイトは、Radarの「HTTP requests」の数字に入らない型である
   2. 減った日が無いので、「いつもの幅」を数えた
   3. 確かめていないこと
8. 08 このテーマの、これまで
   1. 日付つきの記録
   2. 当サイトの、関連する過去の記事
9. 09 この記事のまとめ

01 何が起きたか — Cloudflare Radarのトップが、障害と通信量の地図になった

Cloudflare Blogが、Radarの作り直しを書いた

Cloudflareのブログに、Radarの画面を作り直した経緯を書いた記事が出た。題は「Bridging technical depth and usability: The story behind Radar's redesign」（訳: 技術的な深さと使いやすさをつなぐ ── Radarの作り直しの裏話）で、日付は2026年10月8日と書かれている。2026年10月14日に開いて読んだ。

Radarとは何か。記事の最初の段落は、次のように説明している。

"Radar provides a real-time view into global Internet trends, powered by Cloudflare's global network."

（訳: Radarは、Cloudflareの世界規模のネットワークを使って、インターネット全体の動きをほぼ時間差なく見せる。）

同じ段落は、Radarが2020年に始まったこと、これまでの利用者はネットワークの運用者や研究者が中心だったことも書いている。今回の作り直しは、記者、人権の活動をする人、政策に関わる人、ふつうの利用者にも使ってもらうための見直しだと説明されている。

新しいトップは、地図から始まる

記事によると、新しいトップページは地図を軸にしている。地図の上の部分は、通信量と障害を扱う。障害を先頭に置いた理由は、次のように書かれている。

"We lead with outages as they are one of the most concrete, timely, and salient data points about the state of the Internet."

（訳: 障害を先頭に置くのは、インターネットの状態について、最も具体的で、時宜にかない、目に付きやすいデータの1つだからである。）

地図の下は、以前のカード状のグラフを、切り替えのタブにまとめ直した。タブごとに要約の数字と、詳しく見るための入口が付く。

この記事が読んだもの、読めなかったもの

この記事の材料は、Cloudflare Blogの上の記事、Radarの公式文書（developers.cloudflare.com）、GoogleのSearch Central、Google検索のステータスの一覧である。Radarの画面そのものは、2026年10月14日にブラウザで障害の一覧のページ（Outage Center）を開き、見出しとボタンの名前を読んだ。ただし、一覧の中身（どの国のどの障害が載っているか）は、読み取れなかった。トップの地図の見た目も、この記事では確かめていない。画面の説明は、ブログと公式文書が書いている範囲にとどめる。

この記事の主題は、Radarの使い方の紹介ではなく、自社のアクセスが急に減ったとき、原因がサイトの外にあるかを確かめる順番である。Radarは、その順番の中の1つの道具として出てくる。

02 なぜ・背景 — Radarが見せるのは、Cloudflareの網で見えた範囲である

「インターネット全体」ではなく、Cloudflareの網を通ったもの

Radarの数字を読むとき、まず確かめるのは、誰の目で見たデータかである。作り直しの記事は、Radarの強みを次のように書いている。

"Because Cloudflare sits in front of roughly 20% of all web traffic, Radar has the opportunity to tell unique and compelling stories about the Internet."

（訳: Cloudflareはウェブの通信のおよそ20%の手前にいるので、Radarは、インターネットについて、独自で説得力のある話を伝えられる。）

この文は、見える範囲がおよそ20%であることと、その20%はCloudflareが前に立っているサイトの通信であることを同時に示している。数字はCloudflare自身の説明で、この記事は独自に確かめていない。

HTTPの画面とNetFlowsは、数えているものが違う

Radarの公式文書は、データの種類ごとに説明を分けている。ウェブの要求を扱う「HTTP requests」の説明は、次のとおりである。

"HTTP requests examines complete HTTP requests from end users that reach websites served by Cloudflare's CDN"

（訳: HTTPの要求の画面は、CloudflareのCDNが配信しているウェブサイトに届く、利用者からの完全なHTTPの要求を調べる。）

これに対して、ネットワークの流量を扱う「NetFlows」は、別の範囲を数える。

"NetFlows includes all types of traffic from Cloudflare's routers, not just traffic to websites served by Cloudflare's CDN"

（訳: NetFlowsは、CloudflareのCDNが配信しているウェブサイトへの通信だけでなく、Cloudflareのルーターを通るあらゆる種類の通信を含む。）

同じ「通信量」という言葉でも、ウェブの要求の数を見ているのか、ルーターを通る流量を見ているのかで、意味が変わる。どの画面の数字かを、メモに書くことが、あとで読み返すときの手がかりになる。

値は、元の件数ではない

RadarのAPIの文書は、返ってくる値について、次のように書いている。

"Cloudflare Radar does not normally return raw values."

（訳: Cloudflare Radarは、通常、元の値を返さない。）

代わりに、割合か、最大と最小で0から1に直した値（min-max）が返る。これはAPIの文書の説明で、画面のグラフにもあてはまるかは、この記事では確かめていない。ただ、いずれにしても、Radarのグラフの高さを、自社のアクセス数と同じ単位で比べることはできない。比べられるのは、形（いつ下がり、いつ戻ったか）である。

方法の名前	文書の説明（要旨）	自社の数字と並べるとき
PERCENTAGE	値は割合である	全体に対する割合なので、件数とは並べない
PERCENTAGE_CHANGE	基準の期間からの変化の割合である	基準の期間がいつかを確かめる
MIN_MAX	最小と最大で正規化した値である	同じ要求の中で複数の系列を取ったときだけ、互いに比べられる
MIN0_MAX	最小を0にして正規化した値。全体の最大に対する比で、0から1になる	形を見る。高さを件数に読み替えない
RAW_VALUES	元の値を変えていない	この場合だけ、件数として読める

障害には、場所・ネットワーク・種類・原因が付く

Outage Center（障害の一覧）について、公式文書は、載せる項目を挙げている。場所（Location）、どのネットワークか（ASN）、全国か一部か（Type）、地域や事業者（Scope）、原因（Cause）、開始と終了の時刻である。原因の欄の説明は、次のとおりである。

"Insight into the likely cause of the outage, based on publicly available information."

（訳: 公開されている情報にもとづく、障害のありそうな原因についての見立て。）

「ありそうな原因」と書かれていることに注意する。文書は、これまでの例として、政府が指示した遮断、悪天候や自然災害、ケーブルの切断や停電のような設備の問題、フィルタリングやブロックを挙げている。原因の欄は、断定ではなく見立てである。

アクセスが減る理由は、サイトの外だけではない

Googleの検索の担当は、検索からのアクセスが減る理由を、公式の手引き「Debugging drops in Google Search traffic」（訳: Google検索のトラフィックの減少を調べる）にまとめている。最終更新は2025年12月10日（UTC）と書かれている。手引きは、原因の候補として、アルゴリズムの更新、技術的な問題、セキュリティの問題、スパムの問題、季節性と関心の変化、サイトの移転を挙げ、さらに、集計や記録の側の不具合の可能性にも触れている。技術的な問題について、手引きは次のように書いている。

"Technical issues are errors that can prevent Google from crawling, indexing, or serving your pages to users."

（訳: 技術的な問題とは、Googleがページを巡回し、登録し、利用者に表示するのを妨げうる、エラーのことである。）

つまり、アクセスが減った日の原因は、自社の中、回線やネットワーク、検索の側、数え方の側の4つに分けて探せる。Radarで見られるのは、このうち回線やネットワークの一部である。

03 用語 — 読み違えやすい言葉を先にそろえる

ASN（エーエスエヌ）

正規化（min-max）

UTC・日本時間・米国太平洋時間

障害（outage）と、通信量の異常（traffic anomaly）

Outage Centerのページには、「Internet outages」（訳: インターネットの障害）と「Traffic anomalies」（訳: 通信量の異常）の2つの枠がある。前者は、一覧に原因の見立てや時刻が付く障害で、後者は、通信量の変化から自動で見つけた異常を載せる枠と読める。後者の枠に付いている説明文は、画面で読んだ記録が手元に無いので、原文を引用しない。2つの違いの細かい基準は、この記事では確かめていない。

04 型別 — 自社がどれに当たり、何を、どの順で確かめるか

🅰 型A — ログインや会員登録、予約の画面を持つサイト

この型は、アクセスの減り方が、ログインの完了数や登録の完了数にも出る。外の回線に問題があったなら、完了数も同じ時間帯に下がるはずである。反対に、完了数だけが下がって、ページの表示数は変わらないなら、画面の中の不具合を先に疑う。

🅱 型B — 記事や紹介のページが中心で、検索から来る割合が高いサイト

この型は、Search Consoleの検索パフォーマンスを先に見る。表示回数が同じでクリックだけが減ったのか、表示回数ごと減ったのかで、探す場所が変わる。Googleの手引きは、表示回数もクリックも減った場合は、原因の一覧を見ること、表示回数が同じでクリックだけが減った場合は、タイトルや表示の見え方を疑うことを案内している。

🅲 型C — すでにCloudflareを使っているサイト

この型は、Radarに加えて、自社のゾーンの分析画面がある。Radarの数字はCloudflare全体の集計で、自社の数字ではない。自社の分析データについては、当サイトの記事「Cloudflareの分析データが、すべてのプランで最低30日分になった ── 先月の同じ曜日や障害の日を遡る前に、残す数字を決める13項目（2026年10月時点）」に書いた。

🅳 型D — Cloudflareを使っていないサイト（当サイトもこの型）

この型は、Radarの「HTTP requests」の数字に、自社へのアクセスは入っていない。公式文書の説明は、CloudflareのCDNが配信しているサイトへの要求を数える、という範囲だからである。それでもRadarは使える。自社の訪問者が使う国や回線の側に障害があったかは、サイトの外の話で、Radarの障害の一覧に載りうるからである。

手順1 — 減った時間帯を、日本時間で決める

最初にするのは、Radarを開くことではなく、自社の記録で、減った日と時間帯を決めることである。日単位の集計だけで「昨日は減った」と言うと、半日だけの落ち込みも、一日じゅうの落ち込みも同じに見える。時間ごとの件数が取れるなら、開始と終了を日本時間で書く。Radarの文書は、1日分を取るときの既定の間隔は15分、1か月を超えると1日、と書いている。つまり、短い落ち込みは、期間を長く選ぶと見えにくくなる。Radarで確かめるときも、減った日の前後だけに期間を絞る。

手順2 — 同じ曜日の、前の週と前々週と並べる

減ったかどうかは、前日と比べても分からない。曜日によって、アクセスの量が違うからである。07章に、当サイトのアクセスの記録を1日ずつ数えた結果を載せた。15日の中で、いちばん多い日は、いちばん少ない日の約2.6倍だった。同じ曜日どうしでも、月曜は約1.9倍、水曜は約1.8倍の差が出ていた（日曜は約1.1倍で小さかった）。同じ曜日の2週分と並べて、いつもの幅の外に出たかを見る。

手順3 — 自社の側が、表示できていたかを確かめる

外の障害を探す前に、自社の側を確かめる。主なページを今開いて表示できるか、サーバーのエラー（番号が5で始まるステータス）が増えていないか、ログインや問い合わせの送信が完了しているかを見る。外の障害の話は、自社の側に何も無いと分かってから読んだほうが、納得しやすい。逆に、自社のエラーが同じ時間帯に増えていたら、Radarを開く前に、その原因を調べる。

手順4 — RadarのOutage Centerで、期間を合わせて見る

自社に何も見つからなかったら、Radarの障害の一覧を開く。期間を、手順1で決めた時間帯を含むように選び、場所が日本のもの、または自社の訪問者が多い国のものを探す。Radarの文書の例では、障害の1件に、場所、ASN、種類、範囲、原因、開始と終了が付く。ページには「Download CSV」（訳: CSVをダウンロード）のボタンがあるので、一覧は表にして残せる。時刻はUTCなので、9時間を足して日本時間に直す。

手順5 — 通信量のグラフは、形だけを見る

障害の一覧に該当する行が見つからないときは、Radarの通信量のグラフで、日本の通信量の推移を見る。ここで見るのは、減った時間帯に、同じように下がっているかという形だけである。高さを自社のアクセス数と比べない。形が同じなら、自社だけの問題ではない可能性が上がる。形が違うなら、自社に近い原因を探す。

手順6 — Googleの側を確かめる

検索から来る割合が高いサイトは、Googleの側も見る。Google検索のステータスの一覧（Google Search Status Dashboard）は、「このページは、Google検索を構成するサービスの状態を示す」という趣旨で、巡回（Crawling）、登録（Indexing）、順位付け（Ranking）、表示（Serving）の4つについて、日ごとの状態を出す。2026年10月14日に開いたとき、ページには「No incidents」（訳: 障害なし）と出ており、最終更新は「13 Oct 2026, 22:34 PDT」（日本時間で2026年10月14日の14時34分にあたる）だった。そのうえで、Search Consoleの検索パフォーマンスで、表示回数とクリック数を、前の期間と比べる。

手順7 — 結果を3つに分けて書く

最後に、確かめた結果を、次の3つのどれかに分けて書く。

• 外に原因の証拠がある — 障害の一覧に、同じ時間帯・同じ場所の行があり、自社の側に異常が無かった。
• 自社の側に原因の証拠がある — 自社のエラーや完了数の下落が、同じ時間帯に見つかった。
• どちらも確認できなかった — 証拠が揃わなかった。この場合は、理由を「外の障害は無かった」とは書かない。「見つけられなかった」と書き、次に何を確かめるかを書く。

見る場所	見えるもの	見えないもの	時刻の基準
自社のアクセスの記録	自社への要求、エラー、完了数	訪問者の回線の状態	サーバーの設定による
Radarの障害の一覧	場所・ネットワークごとの障害と、原因の見立て	自社のサイトの状態	UTC
Radarの通信量	Cloudflareの網で見えた通信の形	自社の件数、Cloudflareを通らない通信	画面の表示による
Googleのステータス	Google検索の4つの機能の障害	自社のサイトの状態	米国太平洋時間
Search Console	Google検索での表示回数とクリック数	検索以外からのアクセス	画面の表示による

公式が書いていないこと・確かめていないこと

• Radarの新しいトップの地図に、どの国のどの障害が、いま何件出ているか。トップ画面の中身は読めていない。
• Radarの障害の一覧の載せ方の基準（どの規模から載るか）。文書は項目を挙げているが、基準は書いていない。
• Radarの通信量の異常と、アクセスが減った個々のサイトとの関係。文書は、関係の強さを書いていない。
• Radarの画面の数字が、文書のAPIの値の返し方と同じか。画面の説明は、確かめていない。

05 自分のサイトで確認するチェックリスト

下の13項目は、1項目5分ほどでできる作業である。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。

• アクセスが急に減った日を1つ選び、自社の記録（サーバーのログか計測ツール）で、減り始めた時刻と戻った時刻を、日本時間で書く
• 同じ曜日の前の週と前々週について、同じ時間帯の件数を書き、減った割合を計算して書く
• 減ったのが全体か一部かを見るために、件数の多い上位10ページを並べ、減ったページと変わらなかったページに分けて書く
• トップと主なページ3つをブラウザで開き、表示できたかと、ステータスの番号を書く
• サーバーのエラー（番号が5で始まる応答）の日別の件数を、減った日の前後3日分、数えて書く
• ログインや会員登録、問い合わせの送信の完了数を、減った日と前の週の同じ曜日で並べて書く（画面が無いサイトは「無し」と書く）
• RadarのOutage Centerを開き、期間を減った日を含むように選び、場所が日本の行の件数と、各行の開始・終了の時刻を、日本時間に直して書く
• 項目7で行があれば、ネットワークの欄（ASN）の名前を書き写し、自社の訪問者が使う回線の事業者と一致するかを「はい」「いいえ」「分からない」で書く
• Radarの通信量のグラフで、日本の通信量が、減った時間帯に同じ形で下がっているかを「同じ」「違う」「分からない」で書く（数字は書き写さない）
• Google Search Status Dashboardを開き、巡回・登録・順位付け・表示の4つに、減った日の前後で障害の表示があったかを書く（時刻は米国太平洋時間）
• Search Consoleの検索パフォーマンスで、減った期間と前の期間を比べ、表示回数とクリック数のどちらが減ったかを書く
• 契約しているホスティングやCDN、計測ツールのステータスのページを開き、減った日の障害の有無を、サービスごとに書く
• 項目1から12の結果を1枚の表にして、「外に証拠がある」「自社の側に証拠がある」「確認できなかった」のどれかを書き、日付を付けて保存する

時間が限られているときは、項目1・2・4・5・7の5つだけでも、自社の側の問題か、外の問題かの見当は付く。

06 代替・他の選択肢 — Radar以外で、同じことを確かめる方法

通知を受け取る — Radar Alerts

Radarの公式文書には、通知の機能（Radar Alerts）の説明がある。国や地域、ASNに、通信量の異常、障害、経路の乗っ取り、経路の漏れが起きたときに通知を受け取れる。通知の種類、場所、ASNで絞り込め、送り先は、メール、Webhook、PagerDutyから選ぶ。文書は、この機能がCloudflareのすべてのプランに含まれると書き、設定の手順はCloudflareの通知の文書に案内している。アクセスの減少を毎回あとから調べるのが負担なら、自社の訪問者が多い国を指定して通知を受けるという方法がある。ただし、設定にCloudflareのアカウントが要るかは、文書の書き方から読んだ推測で、確かめていない。

契約先のステータスのページを、先にブックマークする

ホスティング、CDN、メールの配信、計測ツール、決済の会社は、たいてい自社のステータスのページを持つ。Radarで見えるのはネットワークの障害で、契約先のサービスの障害は見えない。減った日に何が起きたかを探す前に、使っているサービスのステータスのページを、一覧にしておくと、項目12が数分で終わる。ページの名前と場所は契約先ごとに違うので、この記事では挙げない。

外から、自社のページを定期的に開く

サイトの外から主なページを開いて、表示とステータスを記録する仕組みがあれば、手順3は、記録を読むだけになる。当サイトの無料ツール🔧 WEBサイトのスクリーンショット、まとめて撮っちゃおツールは、ページを撮影して、画面の見え方を残すのに使える。ただし、これはサーバーの状態の監視ではなく、撮った時点の画面の記録である。

Search Consoleの数字は、見方を先に決めておく

表示回数とクリック数のどちらを先に見るか、どの期間と比べるかを、減る前に決めておくと、慌てずに済む。Search Consoleの画面の見方に迷うときは、🔧 Google Search Console お助け。もうちょっと詳しく知りたいよツールが手がかりになる。どちらのツールも、Radarの障害を判定するものではない。

Radarの数字を、自社の報告に載せるとき

07 当サイトで確かめたこと

当サイトは、Radarの「HTTP requests」の数字に入らない型である

当サイト（WEBサイトサポート）は、Cloudflareを使っていない。2026年10月14日に、トップページの応答の見出しを確かめたところ、CloudflareのCDNを通ると付く「cf-ray」の見出しは付いていなかった。Radarの「HTTP requests」は、CloudflareのCDNが配信するサイトへの要求を数えるので、当サイトへのアクセスは、あの画面に入っていない。この記事の型でいうと、🅳 型Dである。

減った日が無いので、「いつもの幅」を数えた

当サイトのアクセスは、この期間に、急に減った日が無かった。そこで、比べるときの基準になる平常時の幅を、サーバーが残しているアクセスの記録で数えた。数えたのは、2026年9月29日から10月13日までの15日分である。当サイトのサーバーは、HTTPS（暗号化された通信）とHTTP（暗号化されていない通信）のアクセスの記録を、別々に残している。この確認では両方を数えた。HTTPSの記録は15日分で89,485行、HTTPの記録は7,183行だった。圧縮して保管された日ごとのファイルと、回転した直後でまだ圧縮されていない1本の両方を読み、行の中の日付で日ごとに分けた（圧縮ファイルだけを集めると、1日分が落ちる）。数えたのは、1日ごとの要求の件数と、ステータスが5で始まる応答の件数だけである。人間の訪問だけでなく、自動のアクセスも含む。

結果は次のとおりである。

• HTTPSの記録では、1日の件数は3,744件から9,748件の間だった。いちばん多い日（9月30日・9,748件）は、いちばん少ない日（10月8日・3,744件）の約2.6倍である。9月29日（火）は5,738件で、15日の中で目立つ山ではなかった。
• 日曜どうしを比べると、10月4日が5,899件、10月11日が6,465件で、約1.1倍だった。月曜どうし（10月5日の9,564件と10月12日の5,018件）は約1.9倍、火曜どうし（9月29日の5,738件、10月6日の7,731件、10月13日の4,742件）は最大で約1.6倍、水曜どうし（9月30日の9,748件と10月7日の5,375件）は約1.8倍だった。
• ステータスが5で始まる応答は、HTTPSの記録で10月11日に500が8件あった（09時37分台に6件、09時51分台に2件）。ほかの14日は0件である。原因は調べていない。HTTPの記録は、15日とも5で始まる応答が0件だった。
• HTTPの記録だけを数えると、1日の件数は167件から3,228件で、9月29日だけが3,228件と目立った。HTTPSの記録ではこの山は無い。片方の記録だけを数えると、全体の形を取り違える。

この結果から言えることは、限られている。当サイトのアクセスは、曜日によっては、同じ曜日どうしでも2倍近く動く。つまり、「昨日より減った」だけでは、異常かどうかを決められない。減ったと感じたら、同じ曜日の複数の週と並べて、この幅の外かを見る必要がある。これが、手順2の根拠である。

確かめていないこと

この確認は、アクセスの記録を数えただけである。次のことは、確かめていない。HTTPの記録で9月29日だけ件数が多かった理由と、10月11日の500の原因。ログインや問い合わせの完了数（当サイトにその画面があるかも、この確認の範囲外である）。Search Consoleの数字との突き合わせ。そして、実際にアクセスが急に減った日に、Radarの障害の一覧が当サイトの訪問者の回線の問題を示すかどうか。

数字の「0件」や「差」に、見た範囲を書かないと、見ていないことと区別が付かない。この点は、当サイトの記事「AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた」で書いた。アクセスの記録の中で、どれが外部から来た人かを分ける作業は、記事「外部から来た人は19人だけだった ── アクセスログの「参照元」の95.1%は、自分のサイトからの移動だった」に書いてある。

08 このテーマの、これまで

日付つきの記録

日付	出来事
2020年	Radarが始まった（作り直しの記事の説明）
2025年12月10日	Google検索の手引き「Debugging drops in Google Search traffic」の最終更新（UTC）
2026年4月20日	Radarの公式文書の、障害・通知・正規化などのページの最終更新
2026年10月8日	Cloudflare Blogが、Radarの画面の作り直しを説明する記事を出した
2026年10月14日	この記事の確認の日。Google検索のステータスの一覧は「No incidents」

この表で、Radarの新しい画面が公開された日は、ブログの日付から読んでいる。画面が、いつ全員に切り替わったかは、確かめていない。

当サイトの、関連する過去の記事

• CloudflareのBEACONは、大手1万サイトをドメインを外して集計した公開データで、自社の数字は引けない ── 「他社より遅い」と言われたとき、比べる相手を確かめる13項目（2026年10月時点）
• Cloudflareの分析データが、すべてのプランで最低30日分になった ── 先月の同じ曜日や障害の日を遡る前に、残す数字を決める13項目（2026年10月時点）
• Googleがクロールを緊急に減らす手順にRetry-Afterの書き方を加えた。手順そのものは新しくない ── 保守・障害の画面が返す数字を確かめる13項目（2026年10月時点）
• 外部の順位変動レポートと、自分のサイトの記録を突き合わせる手順 ── 『大変動週』は、自社にも起きていたか（2026年8月時点）
• 「アクセスが0でした」と言われて調べたら、仕組みは全部 正常だった ── 壊れていたのは「誰が見に来ているか」の前提
• 「順位が落ちた」と騒がれた週、Googleの公式は何も言っていなかった ── 変動と、自分に起きたことを切り分ける
• 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた