How often does the station update?

Every fifteen minutes. A GitHub Actions workflow polls each upstream feed, normalises payloads into the shared Dispatch schema, runs lifecycle rules, and rebuilds the static site. A tiny client-side overlay patches fresher values on top of the snapshot for time-critical fields like wind, pressure, advisory number, and felt count.

Where does the data come from?

Primary public sources only: the U.S. National Weather Service CAP alert feed for severe weather, the National Hurricane Center for tropical cyclones, and the USGS National Earthquake Information Center for global seismicity. HURDAT2 backs the historical storm archive. PB2002 (Bird, 2003) backs the plate-boundary atlas. Every upstream retains its own license.

Are dispatch URLs stable?

Yes. Every dispatch lives at /events/{id}/ forever. Archived dispatches are immutable. URLs never 404, never redirect, never reshuffle. Post-archival corrections arrive as new linked records via the supersedes field rather than as edits.

Can I cite or embed dispatches?

Yes. Aggregated metadata is CC0. Every dispatch has a durable URL, machine-readable JSON, CAP XML, and OBS-ready browser sources in the Studio. Attribution is appreciated but not required.

Is the data authoritative?

No. Always click through to the source when making a decision. This site aggregates and presents — upstream sources are authoritative. Live overlay freshness depends on upstream availability and our Cloudflare edge cache TTL (60-90 seconds).

Station · Methodology

How the station works

Every dispatch is a cached, revisioned, hash-verified object built from primary public sources. Here's the pipeline.

Pipeline

Every fifteen minutes, a GitHub Actions workflow polls each upstream feed and stores the raw payload with a SHA-256 content hash.
Payloads are normalised into the shared Dispatch schema. New dispatches are created; existing dispatches bump revision when material data changes.
Lifecycle rules move dispatches between active, resolving, and archived.
The static site rebuilds and deploys. A tiny client-side overlay polls /api/live/* to patch fresher values on top of the snapshot for time-critical fields (wind, pressure, advisory number, felt count).

Severity scales

Every dispatch keeps its native scale verbatim — Saffir-Simpson for tropical, moment magnitude (Mw) for quakes, CAP severity for NWS warnings. A normalised 0-100 score is computed alongside so cross-hazard comparisons on the Desk are meaningful.

Severity guides per class live on the dispatch pages themselves. See e.g. the sidebar on any earthquake dispatch.

Lifecycle

Severe weather: active until expiry · resolving for 24 hours · then archived.
Earthquake: active for 1 hour · resolving for 7 days · then archived.
Tropical: active until final advisory · resolving for 14 days · then archived. A post-tropical system that reintensifies can return to active.

Editorial rules

Dispatch briefs are composed by a deterministic rule bank (src/lib/editorial.ts) — no LLM, no external calls. The engine picks the first rule that fires and leads with its fragment, then appends the cleaned upstream summary. Rules cover things like "fourth warning today in this county," "largest quake on the board," "tropical system reintensifying," "tornado emergency," "felt by 500+ people." Rule names are exposed in briefExplained() for downstream feeds.

Immutability & URLs

Archived dispatches are immutable. The URL /events/{id}/ is durable: it never 404s, never redirects, never reshuffles. Post-archival corrections arrive as new linked records via supersedes rather than edits.

Known limitations

Our data is not authoritative. Always click through to the source when making a decision.
Live overlay freshness depends on upstream availability and our Cloudflare edge cache TTL (60 to 90 seconds).
Population-exposure estimates used in severity normalisation are approximations; see the constants in src/lib/severity.ts.