GempaWatch

The problem

Indonesia is the most seismically active country on Earth, and plenty of apps list the latest earthquakes. A list answers the wrong question. What people actually ask is personal: is my city dangerous, should I worry, is it worse here than in Jakarta?

Two gaps make that hard to answer. BMKG, Indonesia's official agency, publishes only its last 15 events per feed, with no history to query. USGS keeps the full archive, but it's global, in English, and returned as raw map data. I built GempaWatch for residents checking their own area, coastal families thinking about tsunamis, students, and journalists who need facts fast during breaking news.

What I built

I merged the national feed with the global archive, then scored it

USGS gives the historical depth. BMKG gives local authority and the smaller felt quakes that USGS never records. When both report the same quake, within five minutes and 50 km of each other, I keep one record and let BMKG's version win. It is the more accurate source for Indonesian events. Nobody can read "217 events above magnitude 4, 14 above 5, 2 above 6". So I combine them into one score out of 100: frequency counts for 40 points, the largest recorded magnitude for 30, the portion of shallow quakes for 15, and closeness to a known fault for 15. The methodology page lists every weight, and the site describes history only, states plainly that it is not a tsunami warning system, and links to BMKG's official alerts.

When the server went away, the build became the pipeline

The first design was a server polling for new quakes every five minutes. About a month in, I moved the public site to GitHub Pages, with no backend. A scheduled job now fetches new events, rebuilds the profiles and publishes the site. To freeze the API, I run the real API code and save its answers as files that mirror the live URLs. The data can't drift from what the server would return.

The browser runs the same risk maths, checked at 39 points

Without a server, the "am I in a risk zone?" check has to run on the phone. I ported the risk engine from Python to TypeScript. Two copies of a formula drift apart over time, so I pinned the server's answers at 39 test points. The deploy stops if the browser version disagrees on any of them. To load about 70,000 events on a phone, I pack them into compact number arrays of about 1.1 MB.

Earthquake history is backed up twice

BMKG only shows its last 15 events, so every older BMKG record exists because an earlier run saved it. Between runs, the database lives in a build cache that can be cleared at any time. I back it up daily, and keep a permanent snapshot every month. If a backup fails, publishing still goes ahead. New earthquake data matters more than the backup.

I rebuilt the homepage and palette around the risk tool

A self-authored design audit found the shipped homepage led with the live map and event list, while the app's actual purpose, a risk answer built from decades of data, sat one click away behind a nav link. I demoted the live feed to a ticker, folded the compare and explore views into region pages as inline context, and made a seismogram of a region's own quake history the page's signature visual. The old dark palette used one colour for buttons, links, headings and a depth band, right next to the risk-tier red, so a HIGH result carried no colour meaning of its own. Chrome is ink-only now; colour is reserved for depth and risk tier alone.

Result

GempaWatch has been live since August 2026, with 70,271 earthquakes from 1970 to 2026, merged across BMKG and USGS. The target in the plan was more than 10,000. The site has a location risk report, profiles for 52 regions with charts, a region leaderboard with compare folded in, a fault and hazard map, shareable risk cards, and a live quake ticker. The full server version, with email alerts, is complete and runs under Docker Compose, but isn't hosted. I built it alone over about three months, in three bursts between July and September 2026.