Relative humidity is what most people reach for when they want to signal “it feels muggy outside.” It’s also the wrong number. A 70% humidity reading at 10°C feels fine. At 30°C it’s miserable. Relative humidity is relative — to the current air temperature — which means it tells you almost nothing about how much moisture is actually sitting in the air pressing against your skin. Dew point does.
Dew point is the temperature at which air becomes saturated. When the current air temperature and the dew point are close together, the air is nearly saturated, evaporation from your skin slows down, and your body loses its main cooling mechanism. The gap between them tells you the story. A dew point below 13°C is comfortable to most people. Cross 18°C and it starts to feel thick. Above 21°C is where the complaints start. Above 24°C is legitimately oppressive — the kind of reading that drives heat illness risk in outdoor workers and athletes.
WeatherAPI’s hourly forecast gives you dewpoint_c and dewpoint_f directly in each hour block. Most developers ignore these fields. They grab feelslike_c and move on. Feelslike is a composite that already has the wind chill/heat index decision baked in — it doesn’t let you isolate the humidity-driven discomfort component specifically, and it doesn’t give you anything to threshold against that has a clean physical interpretation. Dew point does.
What You’re Actually Trying to Detect
The pattern worth catching is a crossover: the forecast hour at which dewpoint_c moves from below a threshold to above it, and holds there. One hour ticking past 18°C isn’t the same as a six-hour window where conditions are consistently above 21°C. These are different alerts with different appropriate responses — one is a heads-up, one is a sustained advisory.
The simplest version of this is a rising-edge detector. Walk the hourly array in order, track the previous hour’s dew point, and fire when you cross the threshold for the first time. That naive version misfires constantly — a brief spike mid-afternoon followed by a drop triggers the same alert as an all-day event. You don’t want that.
What works better is a window-check: find any hour where dewpoint_c exceeds your threshold, then look at the N subsequent hours and count how many also exceed it. If fewer than some minimum count do, skip it. Something like this:
// Pseudocode — adapt for your language of choice
const THRESHOLD_C = 21.0;
const SUSTAINED_HOURS = 3;
function findCrossoverHour(hourlyData) {
for (let i = 0; i < hourlyData.length - SUSTAINED_HOURS; i++) {
const current = hourlyData[i].dewpoint_c;
if (current >= THRESHOLD_C) {
const window = hourlyData.slice(i, i + SUSTAINED_HOURS);
const allAbove = window.every(h => h.dewpoint_c >= THRESHOLD_C);
if (allAbove) return hourlyData[i].time; // Return the crossover time
}
}
return null; // No sustained crossover found
}
This gives you the first hour at which conditions become oppressive and stay that way. If you want the end of the window too — useful for scheduling outdoor work or sporting events — run the same logic in reverse from the tail of the array to find when dew point drops back below threshold and stays down.
Layering in Temperature to Separate Edge Cases
Dew point at 21°C is a lot less alarming at 22°C air temperature than it is at 34°C. The dew point is identical, but the operative mechanism — body core temperature rising because sweat can’t evaporate — is much more of a concern when the ambient heat load is already high. Wet bulb globe temperature (WBGT) is the gold standard for this in occupational health settings, but it requires solar radiation data to compute fully. A reasonable proxy that you can actually build from WeatherAPI fields is dew point combined with temp_c: when both are high simultaneously, you’re in genuine physiological stress territory.
Add a second condition to the filter:
const TEMP_THRESHOLD_C = 28.0;
const isCritical = h =>
h.dewpoint_c >= THRESHOLD_C && h.temp_c >= TEMP_THRESHOLD_C;
This separates “humid but cool” (relevant for outdoor comfort, maybe not for heat stress) from “humid and hot” (relevant for safety). A running app and a construction workforce scheduler have different risk tolerances, and the raw numbers let you encode that difference cleanly rather than collapsing it into a single feelslike value.
A Note on Data Availability and Forecast Horizon
WeatherAPI’s dewpoint_c field is present in hourly forecast blocks out to the full forecast window. For the first 48 hours or so on a US location, the underlying data draws heavily from HRRR or NAM output. HRRR at 3km resolution is genuinely good at capturing thermodynamic conditions in the boundary layer where surface dew point matters most. Beyond 48-72 hours you’re into GFS territory, and dew point values are still directionally useful but shouldn’t be treated as precise enough to trigger automated notifications without a wider threshold margin. A 21°C trigger for day 7 probably wants to be set at 20°C or even 19.5°C to account for the reduced precision of longer-range model output.
There’s also a quirk worth knowing: humidity and dewpoint_c in the API response are computed quantities derived from model fields, not direct observations at the point you queried. Near coastlines especially, local sea surface temperatures can push surface dew points significantly above what the model expects for an inland grid cell at the same coordinate. If you’re building something for coastal users and the alerts feel late, this is a plausible reason — the model grid isn’t always representative of what’s happening in the marine boundary layer immediately onshore.
Making the Alert Actually Useful
Knowing the crossover hour is only half the job. The other half is communicating it in a way that drives action rather than anxiety. A timestamp is useful to a developer. It’s not useful to an end user.
What works: “Conditions become uncomfortable around 11am and stay that way until early evening. Best to schedule outdoor activity before 10am or after 7pm.” That requires both the rising and falling crossover hours, the date context, and a simple template. All of it is derivable from a single hourly forecast call with a day parameter.
One request. One alert. The only logic you’re writing is the crossover detection and a couple of string templates. That’s a real feature with clear utility, built entirely on a field that most developers scroll past when they first look at the response schema.
If you’re not currently surfacing dewpoint_c anywhere in your app, pull a few days of forecast data for a humid location — somewhere in the southeastern US in August, or coastal Southeast Asia — and compare how dew point moves through the day versus how relative humidity moves. The patterns are meaningfully different. Which one you expose to users changes what they can actually do with the information.