A weather-balloon tracking service that began as a joke domain redirect has found itself fielding military requests, aviation investigations and what its operators believe was wartime traffic near the Ukraine-Russia border. The account, published by SondeHub operator Michaela Wheeler, is a sharp example of how a small public API can become consequential infrastructure without its maintainers ever choosing that role.
In Wheeler’s first-person history of SondeHub, the service’s operators say a burst of prediction requests that began in December 2024 was eventually traced to an AWS-hosted workload. Old, deliberately imprecise request plots clustered near the border. Through intermediaries, the team was told that balloon and possibly fixed-wing operators were using wind predictions to help reach target areas.
That explanation is not independently verified in the post, and the published material withholds the raw request data. The responsible reading is therefore narrower than the dramatic headline attached to the original account: SondeHub’s operators saw traffic and received messages they believed were connected to Ukrainian operations. What can be examined directly is the underlying service, its public code and the unusually difficult decisions its maintainers describe.
From a redirect to a global data service
SondeHub started in May 2018 as a shortcut. Weather-balloon enthusiasts were using Habhub, a site built mainly for amateur high-altitude balloons. As meteorological radiosondes became more numerous on the map, Habhub hid them behind a default filter. Registering sondehub.org gave the community a memorable URL that redirected to the filtered view.
The redirect soon grew into infrastructure. The team began proxying radiosonde uploads, storing more of the incoming telemetry and building APIs compatible with Habhub’s frontend. By 2020 and 2021, SondeHub was receiving the full data stream, publishing data through Amazon S3 and running its own flight predictor. When Habhub later shut down, the migration to SondeHub accelerated.
The project’s public infrastructure repository confirms the broad architecture. It describes SondeHub as an AWS-based system that aggregates telemetry from community-operated receivers. The repository contains Terraform configuration for ingestion, querying, historical data, WebSockets and predictors, alongside Python Lambda functions. The live SondeHub tracker offers current and historical flight data, weather overlays, predictions and recovery reporting.
This is useful civilian infrastructure. Meteorological agencies launch radiosondes to measure the atmosphere, while volunteers receive their radio transmissions and recover hardware that would otherwise become litter. Centralizing those observations helps hobbyists find landed devices and gives researchers and other organizations a reusable dataset.
It also creates a detailed picture that official systems may not expose in the same way. Wheeler says SondeHub followed balloons all the way to the ground and developed “reverse predictions”: estimating a launch area by taking observations from a balloon already in flight and running the wind model backward. That made poorly documented launch sites easier to identify. It also produced the project’s first direct encounter with the military implications of its data.
Weather data is dual-use data
In 2021, according to Wheeler, an organization asked SondeHub to stop explicitly marking a sensitive military installation on its map. The inferred location was not the product of a hacked database or classified feed. It emerged from public radio telemetry and a wind model. The team decided to keep reverse prediction available but remove launch sites when it received what it judged to be genuine requests.
The same technique reportedly identified radiosonde launches from military vessels. SondeHub had crossed an important line without changing its original mission: data collected to track disposable weather instruments could also reveal where sensitive platforms were operating.
This is the central technical lesson. “Open” and “harmless” are properties that depend on context, not on a dataset’s file format. A location, timestamp and altitude may look mundane in isolation. A long history of those points, combined with atmospheric models and launch-site inference, can disclose patterns that the data’s producers did not intend to publish.
SondeHub’s predictor introduced a second kind of dual use. A forecast of where a drifting balloon will land is valuable to a hobbyist planning a recovery. The same calculation can help an operator choose a launch point, altitude or time for a wind-borne vehicle intended to travel toward a target. No exotic military model is required. The capability comes from applying ordinary meteorology to a different objective.
The API traffic created a human safety problem
When prediction traffic began spiking in late 2024, Wheeler says the requests appeared to come from one IP address. The team initially suspected an abusive commercial user or a runaway scraper. After plotting prediction locations, it saw the border pattern and began trying to identify the caller.
The maintainers faced a conflict familiar to many small infrastructure projects, but with much higher stakes. The traffic was overloading a shared public service. Normal API operations would suggest rate limiting or blocking the source. If the workload was supporting people in an active conflict, however, abruptly cutting it off could have consequences far beyond an unavailable website.
Wheeler says the team contacted AWS because the source address belonged to its network, while stressing that AWS should neither disclose the request data nor terminate the source account. In the maintainers’ assessment, the logs could expose launch locations and a sudden shutdown could put lives at risk. AWS later connected the two parties after notifying the account holder that a Lambda function appeared to be scraping SondeHub’s API.
The operators then supplied documentation for running the predictor locally. That was a practical resolution: move the heavy, sensitive workload away from a volunteer-run shared endpoint without denying access to the underlying tool. It reduced pressure on SondeHub and limited the need for a third party to send operational queries across the internet.
The episode shows why self-hosting can be a safety feature, not merely a preference about cloud costs or software freedom. A local predictor keeps queries close to the user, avoids exposing every planned trajectory to an API operator and removes a fragile external dependency. For maintainers, distributing the computation also shrinks the category of emergencies they may suddenly be expected to arbitrate.
Small projects inherit institutional responsibilities
SondeHub’s story did not end with that workload. Wheeler reports that the project has received requests from military and government addresses since the 2023 balloon incidents over North America. In one case, the team says a United States defense office requested historical data in 2025. SondeHub proposed charging for the work because it saw no community benefit; the invoice was not paid and the request went no further.
Other contacts were plainly civilian. The US National Transportation Safety Board asked for balloon data after an aircraft incident, Wheeler writes. SondeHub found no matching tracked radiosonde but pointed investigators toward a WindBorne balloon in the area. WindBorne later said one of its balloons was the likely object involved in the October 2025 collision with United Airlines Flight 1093, and described changes to flight planning, real-time tracking and termination procedures.
These interactions reveal a governance gap. A volunteer project can become the most convenient record of an event, even when it has no legal team, round-the-clock operations center or formal process for deciding who receives sensitive data. Once agencies and companies rely on it, “best effort” maintenance collides with expectations usually placed on a commercial provider or public institution.
There is no single policy that solves this. Publishing everything may expose vulnerable operations. Secretly restricting access can undermine a project’s open mission and create pressure to judge political claims. Keeping detailed logs aids abuse investigations but also creates a sensitive dataset that can be demanded, leaked or compromised. Refusing institutional users may protect volunteer time while doing little to prevent those users from obtaining already-public information elsewhere.
The practical safeguards are more prosaic: collect only the logs needed to operate the service, set retention limits, document escalation paths, make bulk processing reproducible off-platform and be honest about what uptime the project can promise. Where location inference is built into a product, maintainers should consider the sensitivity of derived data, not only the raw inputs.
What to watch next
The next question is whether SondeHub turns these improvised decisions into durable policy and tooling. Its public infrastructure makes technical scrutiny possible, but the difficult part is operational: how it handles sensitive launch-site requests, abuse reports, log retention and workloads whose purpose it cannot verify. Other open-data projects should watch closely. A niche API does not need millions of users to become critical; it only needs to be the best available source at the moment someone’s safety, investigation or mission depends on it.