Earthquake24 does not create hazard events and does not predict them. It displays earthquakes and U.S.-focused volcano activity notices reported by the U.S. Geological Survey after deterministic code validates, normalizes, versions and publishes the records.
This page follows the path from motion recorded by seismic instruments to a marker and text entry in the browser. It also documents revision behavior, visible freshness, caching and the production source boundary as it exists on 2026-08-12.
What this methodology covers
The active production data path uses:
- USGS GeoJSON summary feeds for reported earthquakes;
- USGS HANS volcano activity notices, with up to seven days of source history;
- USGS ComCat fields and official event links;
- a private Cloudflare Worker scheduled every two minutes;
- validated, content-addressed JSON in Cloudflare R2;
- short-lived pointers to immutable current packages;
- a static browser application delivered from Cloudflare’s edge.
The production path does not use GDACS. It uses USGS HANS notices as source-attributed U.S. volcano activity reports, not as confirmation that an eruption is occurring and not as globally complete volcano coverage. It also does not use runtime language models, visitor-triggered provider requests, D1, KV, a user-search database, a homemade prediction model, a shaking radius, Google News RSS or Smithsonian GVP data.
This distinction matters: technical support for a format is not the same as an active or approved production source.
From ground motion to an earthquake solution
An earthquake releases energy as seismic waves. Seismometers measure ground motion at their own locations and produce digital seismograms. P waves generally arrive first; S waves arrive later and propagate differently through Earth.
A single station can record motion, but a well-constrained location uses observations from several stations. Networks combine arrival times, amplitudes, station coordinates and a seismic-velocity model. Station count and geometry matter: observations distributed around the source usually constrain it better than stations on only one side.
How an earthquake is located
Automatic or analyst-assisted location software compares observed P- and S-wave arrival times with predicted arrival times from a trial hypocenter. It adjusts latitude, longitude, depth and origin time to reduce the residual difference.
The result is an estimate, not a photograph of the fault. Velocity models simplify Earth, instruments contain noise and some phases are difficult to identify. Depth can be particularly uncertain. Later products for larger earthquakes may include moment tensors, finite-fault models, ShakeMap, felt reports and PAGER. Those products can arrive on different schedules and be revised independently.
Automatic and reviewed solutions
USGS catalog records can include statuses such as automatic, reviewed and deleted.
- Automatic means processing systems published the solution before human verification.
- Reviewed means a person examined the solution; the depth of that review varies and the record can still change.
- Deleted means the source withdrew that record as a current event.
Early values can change when more stations report, phases are repicked, depth improves, another magnitude type becomes authoritative, network IDs are associated or an event is reclassified. Earthquake24 preserves source status and never translates reviewed into “guaranteed final”.
What USGS publishes
USGS recommends its real-time GeoJSON feeds for applications that display earthquake information. Summary feeds cover the past hour, day, seven days and 30 days and are updated every minute. Earthquake24 currently fetches the all_day feed for its one-hour and 24-hour browser windows, the 2.5_week feed for seven days and the 2.5_month feed for 30 days, on its own bounded schedule.
A GeoJSON event can include identity, coordinates, depth, magnitude, magnitude type, place text, origin time, updated time, status, event type, felt reports, intensity fields, PAGER alert, significance, official links and a tsunami field.
The tsunami field does not state that a tsunami exists or will occur. It is source metadata for certain events and is not an Earthquake24 warning.
Open the latest reported events map →
What GDACS adds
GDACS is an external cooperation framework involving the United Nations, European Commission and disaster-management community. Its products can combine hazard information, population exposure, vulnerability and coping capacity to estimate humanitarian relevance. They may be automatic or semi-automatic and carry uncertainty.
This explains why GDACS colors must not be interpreted as magnitude, VEI or a local order. Earthquake24 does not ingest, cache or display GDACS events in production as of 2026-08-12. The adapter remains disabled because the exact endpoint, current schema, redistribution/cache rights and required human review are not complete.
How volcano status is collected
Volcano observatories publish status with institution-specific terms. USGS distinguishes a ground-focused Volcano Alert Level from an aviation-focused Aviation Color Code. GDACS provides a different global humanitarian-impact layer. Presence in either system does not by itself establish that an eruption is occurring at viewing time.
Earthquake24 retrieves USGS HANS volcano activity notices for U.S. observatories. The source endpoint supports a recent-history window of one to seven days. The live package contains the most recent 24-hour subset, while week and month views can expose the notices available within that seven-day source limit. A notice is not proof of a current eruption, and the feed is not globally complete. GDACS remains disabled.
The Earthquake24 pipeline
The production path is deterministic:
- A private scheduled Worker starts on a two-minute cron.
- Cost mode determines whether live, week and month products are due.
- The Worker makes a conditional request to an allowlisted USGS HTTPS endpoint.
- HTTP status, redirects, content type and response size are checked.
- JSON and GeoJSON structure is validated.
- Coordinates, time, magnitude and record ranges are validated.
- Source records are normalized without changing their scientific meaning.
- Event types are filtered, then records are stably sorted and deduplicated.
- Material content receives a SHA-256-derived hash.
- Changed material is written to an immutable R2 object.
- The stored object is read back and its checksum is verified.
- Only then is the small latest pointer updated.
- The browser fetches the pointer and immutable object from
data.earthquake24.net. - Filters and map rendering run in the browser.
An unsuccessful source request cannot replace the last valid package with an empty file. The site Worker serves static assets; it is not a proxy for source calls.
Why we cannot promise zero delay
Several independent clocks exist:
| Time | Meaning |
|---|---|
| Origin time | When rupture began |
| Detection time | When the network had enough observations |
| Source publication time | When a source first published a solution |
| Source updated time | When the source revised it |
| Earthquake24 fetched time | When the scheduled Worker retrieved it |
| Earthquake24 processed time | When validation and publication finished |
| Viewer time | When the browser loaded the package |
USGS summary feeds update every minute, but a record cannot appear before detection, location and source publication. In normal mode Earthquake24 checks the live feed every two minutes, the week feed every ten minutes and the month feed every thirty minutes. Network, CDN and browser caching can add bounded delay. Earthquake24 therefore exposes timestamps and freshness instead of claiming “instant” or “delay-free”.
Field mapping and display rules
| Source field | Earthquake24 use | Limitation |
|---|---|---|
id | Stable source identity | Source associations can change |
mag | Displayed magnitude | Paired with magType when supplied |
magType | Mw, ML, mb, Ms or another type | Not all values are Richter or Mw |
place | Source place description | Not a verified postal address |
time | Rupture origin time | Not source publication time |
updated | Source revision time | Can change repeatedly |
| coordinates 0–1 | Epicenter | Location has uncertainty |
| coordinate 2 | Hypocentral depth | Depth can be weakly constrained |
status | Automatic or reviewed | Reviewed is not final |
type | Earthquake, quarry blast and others | Default map shows earthquakes |
mmi | Instrumental or ShakeMap intensity | Local intensity, not magnitude |
cdi | Community intensity | Depends on submitted reports |
alert | PAGER impact color | Estimated impact, not magnitude |
tsunami | Source flag | Not a tsunami warning |
url | Official source page | The source remains authoritative for its record |
Learn how magnitude and depth should be interpreted →
Revision, deduplication and deletion
Earthquake24 deduplicates records only by exact source event ID. It does not merge events merely because associated IDs, rounded coordinates or place text look similar.
When magnitude, depth, location or place changes, the latest source version replaces displayed fields and the source-updated time remains visible. Each configured USGS product is a full current feed: an item absent from the next successful full feed disappears from that package. A deleted or unavailable record is never transformed into a current report.
The immutable-object history exists to publish safely, not to create a permanent public earthquake archive.
Freshness and stale-data handling
Earthquake packages use these visible age thresholds:
| State | Time since last successful USGS fetch |
|---|---|
| Fresh | 10 minutes or less |
| Delayed | More than 10 minutes and up to 30 minutes |
| Critical | More than 30 minutes |
If USGS is unavailable, Earthquake24 retains the last validated package, ages the state from its real successful-fetch time and retries through a bounded circuit breaker. It does not replace failure with an empty map or refresh the source timestamp merely because the old package was served.
Caching and changed-only publishing
Two R2 object classes have different cache rules:
| Object | Cache policy | Purpose |
|---|---|---|
| Immutable data | public, max-age=31536000, immutable | Content-addressed validated package |
| Latest pointer | public, max-age=120, stale-while-revalidate=600, stale-if-error=86400 | Small mutable reference to current package |
Stable sorting and a material hash prevent repeated immutable writes when scientific content has not changed. The Worker verifies stored JSON bytes with its own SHA-256 metadata; it does not treat an R2 ETag or CDN HIT label as proof of payload integrity. Freshness metadata can update the pointer without rewriting the payload. Browser code deduplicates in-flight requests, polls the pointer every 120 seconds only while the page is visible and online, and reuses immutable hashes; it does not currently send a manual If-None-Match header.
At the daily cleanup slot, the Worker removes inactive immutable live, week and month objects older than 48 hours. The object referenced by each current pointer is always protected, even when older than 48 hours. There is no implemented 30-day daily-snapshot archive in the current production code. This pointer-aware rule prevents retention cleanup from deleting the only current valid package.
What Earthquake24 deliberately does not do
Earthquake24 does not:
- calculate a shaking, impact or safe-distance radius from magnitude;
- convert a tsunami field into an alert;
- relabel every magnitude as Richter or Mw;
- hide automatic source status;
- translate PAGER or GDACS colors into local instructions;
- claim GDACS is active or that HANS notices confirm eruptions or global completeness;
- scrape or republish unlicensed news feeds;
- use Smithsonian GVP commercially without permission;
- generate event values with a language model;
- store user search history or exact geolocation in its data plane;
- claim earthquake prediction.
Privacy, cost and reliability
Article pages and the application shell are static. Normal page views do not start a server render, D1 query, KV lookup or provider request. The browser downloads a cached pointer and data package; only the scheduled ingest Worker contacts USGS.
Changed-only publication, conditional source requests, content-addressed caching and 48-hour cleanup of inactive versions limit operations and storage. Cost modes can slow optional refreshes before account budgets are approached. These are engineering controls, not a promise of zero billing.
Location permission, when selected elsewhere in the application, is processed in the browser for map recentering and is not part of the article or ingest pipeline.
Known limitations
- Global station coverage and detection thresholds are uneven.
- Small earthquakes are not detected equally in every region.
- Automatic events can be false, mislocated or misclassified.
- Depth can be uncertain, and magnitude type or value can change.
- Source place descriptions can be geographically awkward.
- Felt reports depend on population, access and participation.
- ShakeMap and PAGER are model products with uncertainty.
- HANS notices cover U.S. observatories and at most seven days; they are not a global volcano catalog.
- CDN and browser caches can briefly show the preceding valid pointer.
- A missing marker cannot prove that no event occurred.
Common questions
Why did a magnitude change?
More station data, another magnitude method or analyst review may have changed the preferred source solution.
Why did an event move on the map?
The hypocenter may have been recalculated from additional or repicked observations.
Why check every two minutes if USGS updates every minute?
The bounded schedule keeps avoidable delay small without making each visitor generate a provider request. Source detection and publication remain separate timing limits.
Is reviewed status final?
No. A reviewed source record can still change after further analysis.
Does Earthquake24 send early warning before shaking?
No. It displays reported events after source publication.
Does the map use AI for event values?
No. Deterministic code processes the supplied coordinates, magnitude, depth and status.