An official alert feed can be healthy inside its publishing country yet difficult to reach elsewhere. National firewall rules, cross-border filtering and access policies can all interrupt a path between the publisher and an international subscriber.
The Alert Hub RSS reflector is an experiment in reducing that single-origin dependency. It publishes a second, independently hosted route to alerts already collected from an official CAP source. The official publisher remains authoritative; the reflector is a mirror, not a replacement source.
An active mirror, not an HTTP proxy
The reflector does not fetch the official URL when a public reader makes a request. Alert Hub’s normal ingestion process has already retrieved, validated and stored each alert. The public feed is generated from those stored occurrences.
This distinction matters during an origin outage. An alert already received by Alert Hub remains available from the mirror even when the official host cannot be reached by that reader. It also avoids making public reflector latency depend on a fresh request to the national service.
The current implementation only exposes enabled sources. Each alert lookup is scoped to its source, so an identifier from another feed cannot be used to retrieve unrelated content through that route.
A worked example from Mexico
The Mexico SMN reflector mirrors the official CAP feed published by CONAGUA’s Servicio Meteorológico Nacional at:
https://smn.conagua.gob.mx/tools/PHP/feedsmn/cap.phpThe browser view identifies that upstream URL and lists the latest mirrored occurrences in publication order.
The default page contains 50 items and provides a link to the next page. RSS clients receive equivalent pagination links using Atom self, first, previous and next relations. Page size can be selected from 1 to 200 items.
Feed requests do not parse the raw XML of every listed alert. The query uses summary fields projected during ingestion: headline, description, event, sender, sender name and publication time. A title uses the headline when present, then the event, then the CAP identifier. The Mexico rows visible in this screenshot use that identifier fallback. This preserves access to legacy or incompletely projected records without adding a per-request XML parsing loop.
RSS for software, HTML for people
The reflector connects directly to the content-negotiation work described in the previous field note.
The extensionless feed URL responds according to the HTTP Accept header:
curl -H 'Accept: application/rss+xml' \
'https://ah-node-v2.api.alerting-apps.net/public/reflector/mx-smn-es'
curl -H 'Accept: text/html' \
'https://ah-node-v2.api.alerting-apps.net/public/reflector/mx-smn-es'An RSS client receives RSS 2.0. A browser receives the compact HTML index shown above. Explicit suffixes are also available:
/public/reflector/mx-smn-es.xml
/public/reflector/mx-smn-es.htmlThe .xml route uses application/xml, allowing ordinary browsers to show XML rather than opening a download dialog. The unsuffixed machine representation retains its more precise application/rss+xml type. Negotiated responses include Vary: Accept, while explicit suffixes override negotiation.
Each RSS item links to a stable .xml representation of the mirrored CAP alert. The HTML feed instead links to its extensionless address, allowing a browser to receive a readable page.
From a feed item to the CAP alert
The first item in the worked feed resolves to this mirrored CAP alert.
The alert resource uses the same pattern as the feed:
curl -H 'Accept: application/cap+xml' \
'https://ah-node-v2.api.alerting-apps.net/public/reflector/mx-smn-es/d71c430d-b73a-54bc-afa0-98eeca289d5c'
curl -H 'Accept: text/html' \
'https://ah-node-v2.api.alerting-apps.net/public/reflector/mx-smn-es/d71c430d-b73a-54bc-afa0-98eeca289d5c'CAP software receives the stored CAP XML. A browser receives HTML with the mapped alert geometry and structured alert, information and area fields. .xml and .html suffixes provide deterministic alternatives when a client cannot set Accept reliably.
Only the selected alert is parsed to create its HTML view. This is separate from generating the RSS page and keeps feed rendering proportional to the projected rows rather than to the size of every stored CAP document.
Caching and conditional requests
The feed and alert responses include validators and short public cache periods. The live deployment currently uses a one-minute cache lifetime for feeds and five minutes for alerts. ETag and Last-Modified allow clients and intermediaries to make conditional requests and receive 304 Not Modified when appropriate.
This reduces repeat transfer without making the active feed appear static. The RSS feed also reports its latest build time from the newest mirrored occurrence.
What this does—and does not—provide
An alternate host can help when a subscriber cannot reach the official national origin but can reach Alert Hub. It also leaves a retrievable copy of alerts that Alert Hub received before a later origin failure.
It is not a guarantee of delivery. Alert Hub must first receive the alert; ingestion can be delayed or interrupted; the mirror can itself be filtered or unavailable; and it does not establish a second official publisher. Consumers should retain the CAP sender, identifier and source provenance when deciding how to trust and use a mirrored alert.
The present work establishes the HTTP and presentation mechanics: an RSS feed derived efficiently from stored alert metadata, stable links to the original CAP payloads, browser-readable alternatives, pagination, caching and explicit provenance. Further resilience depends on operating multiple genuinely independent routes and monitoring the delay between official publication and mirrored availability.