The Philippines sits on the Pacific Ring of Fire and right in the typhoon belt. Earthquakes, typhoons, floods, volcanic eruptions, wildfires. If you live here, disaster season isn't a season. It's the calendar.
When a typhoon hits the Philippines or an earthquake jolts you awake at 3 AM, you're checking PAGASA for storm bulletins, PHIVOLCS for seismic data, GDACS for severity alerts. Each one covers a single hazard type. None of them give you one clean view of what's happening. A bagyo is bearing down on Luzon and you're toggling between three tabs trying to figure out: how bad is it, and where?
So I built a Philippines disaster tracker called Sakuna. Real-time earthquake monitoring, typhoon tracking, fire hotspots, flood alerts, and volcanic activity on a single map and dashboard.
The Weekend Warrior Approach
I didn't block out a sprint for this. I had a pain point, a free Saturday, and a glass of whiskey. I sat down with Claude (my AI coding partner, via Claude Code) and we mapped out the requirements in about ten minutes:
- Aggregate data from every free public disaster API that covers the Philippines
- Normalize everything into one schema so earthquakes, typhoons, and fires show up the same way
- Host it for free. Zero monthly cost.
- Ship it live. Not a side project that sits in a repo.
The entire thing went from a conversation to a production deployment in a weekend's worth of sessions. Not because I'm fast, but because the infrastructure was already there.
The Stack: Cloudflare Free Tier, Zero Cost
Everything runs on Cloudflare's free tier. No servers. No database bills. No Hostinger, no Vercel, no AWS.
CF Worker (cron every 15 min)
├── Fetches 5 public APIs
├── Normalizes events to unified schema
├── Filters to Philippines bounding box
└── Stores results in R2 object storage
Cloudflare R2
├── events.json (all current disaster events)
└── health metadata (per-API status + timestamps)
Cloudflare Pages (static frontend)
├── Leaflet dark-theme disaster map
├── Dashboard cards by hazard type
├── Filter chips (earthquake, typhoon, fire, volcano, flood, rain)
└── Staleness indicator (LIVE / DELAYED / OFFLINE)
The worker runs on a cron trigger every 15 minutes and writes static JSON to R2. The frontend polls that cached JSON from Cloudflare Pages (which has unlimited free bandwidth), not the Worker itself. So the Worker stays well within the free tier's 100K requests/day limit, and the frontend can poll every 30 seconds without cost implications. Total Cloudflare bill: $0.
Five Free APIs, One Unified Disaster Schema
The hardest part wasn't the code. It was figuring out which government and scientific APIs actually work, which ones have usable data, and how to normalize them into something consistent.
| API | What It Covers | Data Format |
|---|---|---|
| USGS FDSNWS | Earthquakes M2.0+ in the Philippines | GeoJSON |
| NASA EONET | Volcanoes, wildfires, storms | JSON |
| GDACS | Multi-hazard severity alerts | RSS/XML |
| NASA FIRMS | Satellite fire hotspot detection | CSV |
| PAGASA | Philippine typhoon bulletins | HTML (scraped) |
Every event from every API gets normalized into one schema:
{
"id": "usgs_us7000abcd",
"type": "earthquake",
"title": "M5.2 - 23km SE of Davao",
"severity": "high",
"lat": 6.9,
"lon": 125.5,
"occurred_at": "2026-04-10T03:15:00Z",
"url": "https://earthquake.usgs.gov/..."
}
Severity mapping is specific to each data provider. Earthquakes use magnitude thresholds (M4.0+ = moderate, M5.0+ = high, M6.0+ = critical). GDACS uses its own green/orange/red alert system. FIRMS maps satellite confidence scores. PAGASA typhoon signal numbers translate directly to severity levels.
Graceful Degradation: When APIs Go Down
This was a deliberate design decision. If NASA's FIRMS API goes down (it does, regularly), the other four keep working. Each data provider has its own health indicator on the dashboard. One going offline dims its status pill. The earthquake map, typhoon tracking, and flood data keep updating.
For a disaster tracker, this matters. The worst time for a monitoring tool to break is exactly when people need it.
The Philippines Bounding Box Problem
You can't just query these APIs globally and filter later. The data volumes are too high and the APIs rate-limit you. So every request is scoped to a geographic bounding box covering the Philippine archipelago: [116.9, 4.5] to [127.0, 21.5].
But the Philippines has a geographic quirk. The southern boundary overlaps with Malaysia's Sabah region. Without a second filter, you get fire hotspots from Borneo showing up as Philippine events.
function inPhBbox(lat, lon) {
if (lat > 21.5 || lat < 4.5 || lon > 127.0 || lon < 116.9) return false;
// Below lat 7: only include Sulu/Tawi-Tawi, exclude Sabah
if (lat < 7.0 && lon < 119.0) return false;
return true;
}
Small detail, but it matters. Nobody wants to see Malaysian wildfires on a Philippines disaster map.
Why This Didn't Take Longer
I've been running Claude Code as my primary development tool for months. Over time I've built an operational layer around it: persistent memory, deployment pipelines, API connector patterns, and gates that catch mistakes before they ship.
When I sat down to build Sakuna, I didn't start from zero. The AI already had context on my Cloudflare patterns, my code conventions, and my deploy commands. And the harness I'd built around it handled the operational side: verifying deploy targets, enforcing structure, preventing the kind of drift that turns a weekend project into a weekend debugging session.
I didn't build fast because I typed fast. I built fast because months of workflow engineering compressed the distance between "I have an idea" and "it's in production."
The Result
Sakuna is live, free, and serving real data to anyone who needs it. It tracks earthquakes in the Philippines in real time, monitors active typhoons, detects fire hotspots via satellite, and surfaces flood and volcanic alerts. It auto-updates every 15 minutes. It costs nothing to run.
Is it perfect? No. The PAGASA typhoon parser is regex-based and fragile against page redesigns. PHIVOLCS isn't integrated yet because their SSL certificate has issues. There's no historical archive. These are known limitations, not surprises.
But it works. It's useful. And it shipped.
The Weekend Ritual
I keep coming back to Sakuna between other projects. Add marker clustering one evening. Tighten the bounding box to exclude Sabah fire noise another morning. Build a crawlable about page with FAQ schema over lunch. Wire up a rainfall overlay from Open-Meteo weather stations on a Sunday.
It's become one of my weekend rituals. Find something that could be better about the tracker, plan the fix with Claude, ship it before dinner.
The point isn't that I built a disaster tracker. The point is that the tools exist to go from a pain point to production in a weekend, if your workflow is set up for it. The APIs are free. The hosting is free. The AI assistant costs less than a coffee subscription. The only real cost is your time and maybe a decent whiskey.
Sakuna is live at sakuna.tokita.online. If you're in the Philippines during the next typhoon or earthquake, it might be useful. If you're a developer with a side project idea collecting dust, maybe this is the nudge.
What free APIs or Cloudflare patterns have you used for your own weekend projects? I'm always looking for new data pipelines to wire in.
Tom Tokita is an AI Operations Architect in Manila. He writes about what works (and what breaks) when you put AI agents into production.
Top comments (0)