DEV Community

owen
owen

Posted on

I built a tool that turns aurora data into a single decision: GO, MAYBE, or NO

Every time a geomagnetic storm makes the news, the same thing happens in my household: someone asks "can we see the northern lights tonight?", and I open three tabs — a Kp index chart, a cloud forecast, and a light pollution map — and still can't give a straight answer.

The existing aurora tools are built by and for space-weather people. They show you the raw data: planetary K-index, aurora oval plots, solar wind speed. That's great if you know what "Bz = -12 nT" means for your driveway. Most people don't. Some sites go the other way and print invented precision like "73% chance of aurora tonight" — a number nobody can honestly produce.

So I built Aurora Tonight (aurora-tonight.com): enter your city or ZIP, get one of four answers — GO, MAYBE, NO, or UNKNOWN — plus the best viewing window, the main obstacle in plain language, and which direction to look.

The stack

Nothing exotic, and that was the point:

  • Next.js on Vercel. Forecast pages are served via ISR — the answer for a given city only changes as fast as the upstream data does, so per-request rendering was just burning invocations for identical bytes.
  • NOAA's aurora oval data for geomagnetic activity. This is the authoritative public source; I deliberately don't layer a proprietary "prediction" on top of it.
  • Open-Meteo for cloud cover snapshots. Clouds are the #1 reason a strong geomagnetic night is still a NO, and most aurora sites ignore them entirely.
  • Darkness, moonlight, and light pollution are computed or looked up server-side. Everything is cached at the edge; the whole site is static-ish and free to run, which is why the tool can be free with no signup.

The interesting design decision: what not to compute

The hardest part wasn't the data pipeline — it was deciding the output contract. Three rules I ended up with:

  1. No fake percentages. The model's output is a categorical call, not a probability. If you can't defend "73%", don't print it. GO / MAYBE / NO maps to what a person actually does with the answer.
  2. UNKNOWN is a first-class state. If the cached data snapshot is stale, the page says UNKNOWN instead of extrapolating a confident-looking guess from old data. This costs us some "always has an answer" slickness, and it's worth it.
  3. The main obstacle is part of the answer. "NO" alone is useless. "NO — overcast until after 1am" tells you whether to set an alarm.

I wrote up the full scoring logic on the methodology page if you're curious how the calls are made — it documents exactly what goes into a GO versus a MAYBE.

Current scope and honest limitations

It covers 15+ indexed US states and cities — Fairbanks and Alaska down through mid-latitude places like Colorado, Ohio, and Chicago, where aurora is a rare-event question rather than a nightly one. Northern hemisphere, mid-to-high latitudes only. It won't tell you anything useful in Texas, and it says so.

If you're building anything in the "raw public data → plain-language decision" space, I'd genuinely like to hear how you handled the honesty-vs-slickness tradeoff. The temptation to print a number that looks more confident than the data deserves is real.

Top comments (0)