Three months and counting!
It’s hard to believe it has only been three months since I started building FirePing. This project has been squeezed into the margins of my life - early mornings, late nights, and whatever I can carve out between work, being a dad, and being a husband. Slow progress, but steady progress.
When I started, the goal was simple:
Create a system where anyone could set up locations to monitor and get notified fast when satellites detect a wildfire in designated locations.
Web push. SMS. Email. That was the initial target.
Then I kept going.
I added an API so developers could automate monitoring. I drafted an MCP integration so users can literally ask an AI about their sites and detections. I built webhooks so FirePing can plug into whatever workflows people already use - Slack, Discord, homegrown tooling, you name it.
The early version
Version 0 was humble:
- Only a handful of satellite sources
- No notification system
- A map renderer that hated large datasets
But it worked. Barely - but it worked.
The dashboard today
The new dashboard feels like a real product. There’s a timeline feature so you can see how a fire evolves over time. The map now switches between 2D, 3D, satellite, dark tiles, and even elevation tiles - super useful when trying to understand how a fire might run through valleys, ridges, or mountain bowls.
People have started using it. Not many yet, but enough to give real, actionable feedback. And honestly, every user feels like a milestone.
Satellite coverage
Right now FirePing processes active fire detections from:
- NOAA-20 VIIRS
- NOAA-21 VIIRS
- S-NPP VIIRS
- GOES-18
- GOES-19
- Meteosat MTG2
- Meteosat MTG3
- MODIS
Coming soon:
- Himawari
- Landsat 8-9
This mix of polar-orbiting and geostationary satellites is what gives FirePing both depth and speed. Geostationary systems like Meteosat, GOES and Himawari can capture new fire activity every 10-15 minutes, depending on the satellite - which is critical for fast-moving fires, or the ones that flare up between VIIRS/MODIS overpasses.
The pipeline under the hood
FirePing checks for new data every 10 minutes. When new detections appear, they’re ingested, normalized, and written into a central detection table.
A notifications worker then takes over:
- Compare new detections against every user-defined location.
- Trigger notifications when thresholds are met.
- Fan out alerts through email, SMS, web push, and webhooks.
Right now the ingestion runs sequentially. That was a deliberate constraint - because in the beginning everything was running on a $5/mo VPS, and processing rasters in parallel would simply kill the machine.
But that era is over.
FirePing is now running on a beefy self-hosted server with more than enough compute to get me well into 2026. It also unlocks something I’ve wanted from day one:
parallel ingestion with higher frequency checks.
That alone will make the system faster, more responsive, and more resilient.
The one-year target
I’ve set myself a one-year runway to get FirePing fully ready for the 2026 European fire season. The core service is running today, but there’s more refinement to do - UX, performance, data coverage, onboarding, documentation, integrations.
And something I haven’t announced yet: this new infrastructure also gives me room to explore a second product idea in the same space. More on that soon.
Looking back and ahead
Three months in, I’m proud of the momentum. Not the speed - because this isn’t a blitzscale story - but the consistency. FirePing is the kind of project that rewards stubbornness more than brilliance.
And the mission still feels urgent:
turning satellite detections into automated protection.
There’s a lot more to build, but the foundation is finally solid.
