If you’re reading pressure_mb from a WeatherAPI response and comparing it against some threshold — “low pressure means bad weather” — you’re doing less useful work than you think. A reading of 998 mb tells you almost nothing on its own. Is it falling, rising, holding? At what rate? That’s where the actionable signal lives, and it’s not a field the API hands you directly. You have to derive it.
What Tendency Actually Measures
Pressure tendency is the rate of change in surface pressure over a defined interval — traditionally 3 hours in SYNOP and METAR reporting, codified in WMO Manual on Codes No. 306. The direction and magnitude of that change is far more predictive of imminent weather than the absolute value at any single moment.
A pressure of 1012 mb that has dropped 4 mb in the last three hours is more alarming than 998 mb that’s been flat for 12 hours. The first is an active gradient developing; the second is just a stable low sitting over you with nothing changing. The first generates the kind of rapid deterioration that ruins a same-day outdoor shoot or pushes a site drone fleet to ground. The second one you’ve already adapted to.
NWS uses this rough scale for 3-hour change magnitude:
- 0–1.5 mb: slow change, minimal short-term significance
- 1.6–3.5 mb: moderate change, developing pattern worth tracking
- 3.6–6.0 mb: rapid change, likely frontal passage or approaching storm
- Over 6.0 mb: very rapid change — explosive development or strong frontal system
These aren’t hard rules. But they’re grounded in how synoptic meteorology classifies systems, and they’re a much better basis for alerting logic than “pressure is below X mb.”
Deriving It from WeatherAPI’s Hourly Forecast
WeatherAPI’s forecast endpoint gives you hourly pressure_mb values going forward, and the history endpoint gives you the same field looking backward. Neither gives you a pre-computed tendency field — it’s a derived quantity you calculate yourself. Two lines of arithmetic, but getting the window right matters.
For real-time alerting, fetch current conditions plus the last three hours of history and compute the delta:
GET /v1/history.json?key=YOUR_KEY&q=55.8642,-4.2518&dt=YESTERDAY&end_dt=TODAYThen in your application layer:
// C# example
double pressureNow = currentConditions.PressureMb;
double pressureThreeHrsAgo = historyHour.PressureMb; // same-location, T-3h
double tendency = pressureNow - pressureThreeHrsAgo;
string classification = tendency switch {
< -6.0 => "very_rapid_fall",
< -3.5 => "rapid_fall",
< -1.5 => "moderate_fall",
<= 1.5 => "steady",
<= 3.5 => "moderate_rise",
<= 6.0 => "rapid_rise",
_ => "very_rapid_rise"
};For forward-looking logic — deciding whether to flag the next 6 hours as high-risk for an outdoor event app, say — use the hourly forecast values instead and compute tendency across the upcoming window:
// Look at pressure trend over forecast hours 1 through 4
var forecastHours = forecastDay.Hour; // WeatherAPI hourly array
double pressureStart = forecastHours[1].PressureMb;
double pressureEnd = forecastHours[4].PressureMb;
double forecastTendency = pressureEnd - pressureStart; // over ~3 hoursThat gives you a forecast tendency — not a measured one, but still more useful than watching a static absolute value.
Where This Actually Helps
Outdoor scheduling apps are the obvious case, but the pattern extends further. A few worth calling out:
Construction site alerts: A rapid pressure fall in the 3–4 hours before a shift ends is a more reliable wind/rain precursor than an amber condition code, which often lags by 30–60 minutes. If you’re automating communications to a site manager, tendency-based alerting gives you lead time the condition code doesn’t.
Agriculture and pest management: Fungal pressure tends to spike around frontal passages where humidity and pressure swing together. Combining a rapid pressure fall with high relative humidity and low wind is a much stronger pre-spray trigger than any single field.
Aviation pre-flight decision tools: Rapid falls near coastal departure airports frequently precede the ceilings and low-vis conditions that turn a VFR flight into an IFR situation faster than the TAF update cycle catches. Tendency gives a semi-independent check on whether conditions are actively evolving rather than just sitting at a bad-looking snapshot value.
A Genuine Limitation Worth Knowing
Pressure tendency works well for synoptic-scale systems — fronts, mid-latitude cyclones, the patterns that move and evolve over hours. It’s much less useful for convective events. A pop-up thunderstorm in summer can go from clear skies to hail in 45 minutes, and the surface pressure signal for that is small and localized — a 3-hour tendency window won’t reliably catch it. For convective risk you need lifted index, dewpoint, CAPE, and a 500 hPa analysis, not surface pressure alone.
The pressure_mb values in WeatherAPI’s forecast output are also model-derived, not measured. They come through our GRIB2 ingestion pipeline from GFS or ECMWF depending on lead time and location, and they represent the model’s best estimate of mean sea level pressure at that hour. That’s fine for tendency calculations — the model is internally consistent, so deltas are meaningful — but don’t apply the same confidence you’d give a 3-hour measured SYNOP tendency at a staffed station. The signal is real; the precision isn’t equivalent.
How to Weight It Against Other Signals
Tendency works best as a multiplier rather than a standalone trigger. A moderate pressure fall combined with a condition code already showing overcast and humidity near the dewpoint is a much stronger alert candidate than a rapid fall under clear skies, which sometimes just means a dry air mass moving in fast. The compound-condition pattern — combining dewpoint, humidity, and pressure for storm detection — applies here too. Tendency is one leg of the stool, not all three.
A reasonable pattern: classify tendency as above, then gate on at least one corroborating signal (cloud cover above 75%, dewpoint spread under 3°C, or a forecast condition code already indicating precipitation) before firing an alert. That combination cuts false positives substantially without adding meaningful latency to detection.
If your app currently has a single pressure threshold in it — below 1000 mb, or similar — try swapping it for a tendency check over the next real test dataset you run through it. You’ll almost certainly find cases where the threshold fired on nothing and missed a rapid-fall event that happened entirely within the “normal” pressure range. That’s not fixable with a better threshold. It’s the wrong measurement entirely.