Most developers who integrate wind data treat gust_kph as “wind_kph but louder” — a slightly higher number you can largely ignore unless it’s extreme. That framing will quietly break your application for any use case that actually depends on wind.
They’re not measuring the same thing. Sustained wind (wind_kph) is a time-averaged value — typically a 10-minute mean as defined by WMO standards for surface observations. Gusts are a different statistical beast: the peak 3-second average recorded within the observation period. You’re comparing a 10-minute mean against a 3-second peak. The number of independent samples, and therefore the variance, is completely different.
Why That Difference Matters in Practice
A 10-minute mean of 30 km/h with gusts to 55 km/h isn’t unusual in an unstable post-frontal airmass. But the gap between those two numbers — 25 km/h — carries real information that gets lost if you only threshold on one field.
For construction site safety: sustained winds above roughly 50 km/h are a common threshold for halting crane operations. But a site seeing 38 km/h sustained with gusts to 62 km/h is almost certainly more operationally problematic than one seeing 42 km/h sustained with gusts to 48 km/h, even though the second site has higher sustained wind. The first site has unpredictable mechanical loading on the boom — that’s what gust amplitude relative to sustained actually tells you.
For drone flight, regulatory and practical thresholds are almost always specified in terms of peak gust, not sustained wind, for exactly this reason. A drone that can handle 40 km/h sustained will have control surface authority stripped in a 65 km/h gust regardless of what the 10-minute mean looks like.
For event management and outdoor structures: sustained wind loads structures continuously; gusts are the mechanism that actually topples them. Structural engineers designing temporary shelters use gust factors explicitly — it’s standard practice, not an afterthought.
The Gust Factor and What It Tells You
The ratio of gust_kph to wind_kph — the gust factor — is a useful derived signal. Over flat open terrain, a gust factor around 1.4 to 1.6 is fairly typical. When it climbs above 2.0, that’s a sign of significant atmospheric instability or convective activity nearby: the turbulent structure of the boundary layer is very non-uniform, meaning the wind environment is much harder to predict within a short time window.
A gust factor above 2.5 with sustained winds already above 25 km/h is a combination worth flagging as a high-risk window for outdoor operations regardless of the raw sustained speed. You can compute this in one line:
gust_factor = hour["gust_kph"] / hour["wind_kph"] if hour["wind_kph"] > 5 else NoneGuard the divide-by-near-zero case. When sustained wind is very low, the gust factor becomes meaninglessly large and will throw off any alerting logic downstream.
Where the API Data Actually Comes From
For current conditions, both fields derive from METAR observations, which report peak gust directly in the coded string (the G token between sustained speed and direction — e.g., 27015G28KT). When no gust is explicitly encoded — meaning the peak 3-second wind didn’t differ from the mean by 10 knots or more during the observation period — METAR omits the gust field entirely. We handle this in our condition mapping by propagating the sustained value rather than leaving the field blank, but the implication is that gust_kph equaling wind_kph in an API response doesn’t necessarily mean there were no gusts; it may mean the gust amplitude was below the METAR reporting threshold.
For forecast hours, the data comes from NWP model output — HRRR at 3 km grid resolution for the US, GFS at roughly 13 km for global coverage beyond HRRR’s domain. Both models output 10m wind gust as a separate diagnostic variable, not something derived post-hoc from the sustained wind. HRRR’s gust parameterization is based on the turbulent kinetic energy scheme in the boundary layer, which is one reason HRRR tends to give more credible gust forecasts in convective environments than GFS does at coarser resolution.
The practical upshot: for the contiguous US within roughly 48 hours, the gust forecast in the API is coming from a physically-motivated model field, not a statistical multiplier on sustained wind. Outside that domain or beyond 48 hours, it degrades toward GFS, and GFS gust values in complex terrain or near convection should be treated with more skepticism.
Building Sensible Thresholds
Most applications need a two-condition check rather than a single threshold:
- Absolute gust ceiling: flag any hour where
gust_kphexceeds your use-case-specific hard limit (62 km/h for light drone ops, 75 km/h for outdoor events, etc.) - Gust factor ceiling: flag any hour where the ratio exceeds roughly 1.8 to 2.0 and sustained is above a minimum threshold (e.g., >15 km/h), to catch high-variability windows even when absolute speeds look acceptable
Running only the first check is the common mistake. A sustained wind of 20 km/h with gusts to 48 km/h won’t trip most absolute gust thresholds, but the environment is genuinely turbulent and the 10-minute average is masking significant moment-to-moment load variation.
Suppress the gust factor check when sustained winds are very calm — below about 5 to 8 km/h — because a puff of 12 km/h in otherwise still air shows up as a gust factor of 2+ but isn’t operationally meaningful in the same way.
One Caveat Worth Keeping in Mind
Gust observations from METAR stations are point measurements at 10 meters above ground, typically at an airport or similar open exposure. The representativeness problem that affects sustained wind — a station 15 km away may not reflect local channeling through a valley or acceleration over a ridge — applies equally or more to gusts, since gusts are also sensitive to local surface roughness. Our station-selection scoring tries to pick the most representative station for a given coordinate, but no scoring system substitutes for local knowledge of terrain effects. If your application is sited somewhere with known exposure issues, treat forecast gust values as a baseline floor, not a ceiling.
If you’re currently only thresholding on wind_kph, pull the last week of hourly data for one of your target locations and compute the gust factor distribution yourself. It’s a quick query against the history endpoint, and the distribution will tell you pretty directly whether your current logic is ignoring the more operationally relevant field.