気象庁防災情報XML形式によるデータ公開は、2012年12月17日から始まった WebSub プロトコル（旧称PubSubHubub）による PUSH 型提供に加えて、Atom Feed により HTTPS GET だけで構築できる PULL 型提供が行われています。
ご紹介は前回書きました https://qiita.com/e_toyoda/items/185c1dea055e230918b9
PULL 型提供は利用者のみなさまのご要望で追加されたものですし、中の人としても CDN の活用により利用者数に対してスケールする効率的なものですから、これをデジタル・トランスフォーメーションの基幹として推進するくらいのつもりでいるのですが、どうも新しいものは品質が心配という話がよく聞こえてきます。
以下のように考えているので、ダメだったら @etoyoda （twitter:e_toyoda） に教えてください。
2021-12-16 補足：HSTS化にご注意ください
https://qiita.com/e_toyoda/items/19b53286264cfe47ba9f
フィードの更新が遅い
すみませんキャッシュ設定が悪かったです。かなり早くなりました。
HTTP ヘッダを読める人ならだれにでもわかることですが、2019年9月12日までは max-age: 600 としていました。これにより CDN キャッシュサーバが古い応答を返していました。今は max-age: 60 です。
（2021-01-06 追記：昨日まで max-age: 600 になっていました。2020年11月頃からだと思います。
今は60に戻しています。監視することにしました。）
フィード内容に漏れがある
すみませんキャッシュ設定が悪かったです。もう漏れないと思います。
過去10分間（＝600秒）の新着電文を記載するフィードが、オリジンサーバで毎分更新されており、これを max-age: 600 のキャッシュサーバ越しにアクセスすると、一部新着電文が見られないことがあります。説明が長くなるので、どっかで解説があったら引用したいのですが。
フィードを逐次取得すると巻き戻ることがある
受信者さまで地理冗長した複数クライアントシステムをお持ちではないでしょうか。正確には所在府県市町村ではなく、経路と CDN キャッシュサーバが別になると、CDN による遅延が異なり、フィード巻き戻りが報告されたことがあります。私が個人的にやっている受信試験（さくらのVPSの単独クライアント機）では、巻き戻りは観測されていません。
CDN はやめられないですのでご容赦ください。CDN 遅延量は上記設定変更により大幅に縮小したので、巻き戻りはなくすことはできなくても幅は小さくなるでしょう。
関連して、重複 uuid のチェックは、複数クライアントの consolidate をするならどのみちやめるわけにはいかないでしょう。また、PUSH 型でも重複配信が起こらない保証は Google Public Alert 側でしていなかったし、現に 2012 年にログをよく見ていたときにはけっこう重複配信が起こっていたと記憶しています。
フィードに書かれた電文本体の URL にアクセスしたら 404 だったことがある
すみませんが絶対ないとは言えません。リトライしてください。
個人的には観測していないので分析が進んでいません。
遅延量どんくらいなの
図中、オレンジの線がPULL型の遅延量ヒストグラムです。棒グラフにしないと怒られるのでしょうが、多数要素を比較したいののでご容赦ください。フィード作成から８０秒（秒の位を切り捨てているので８９秒と言ったほうが良いでしょう）以内に９０％の電文の本体ダウンロードまでできています。２０秒と８０秒に山があって、この比率は毎分２０秒起動というチューニングでよくなりました。
図中緑の線は比較のためPUSH型の遅延量ヒストグラムです。手が回らずPOSTメソッド処理までしか書いておらず、電文本体の取得保存にかかる時間が入っていませんが、まあ数秒でしょう。一見すると最頻値がギリギリ１０秒だったり、５９秒以内に９０％の電文の更新が通知されたり、多少優秀ようにも見えますが、たまに２時間近い巨大遅延配信があったりして、Alert Hub内部のことですからよくわかりませんが、品質が高いと手放しで褒められるものではありません。
まあ、ざっくりいうと、PULL型提供でも概ねPUSH型と同程度の品質は達成できた、と受け止めています。
図中灰色の線は、気象庁内での取り扱いにかかる時間です。データの種類ごとに庁内での配信も異なるので、平べったいグラフになっていますが、全体としてみれば１分程度の遅延はあります。
