If you’re building an outdoor activity app and using uv_index alongside cloud to decide when to warn users, you’ve probably noticed they don’t always move together. Cloud cover reads 60% while UV index sits at 8. That’s not a data error. It’s how UV actually behaves — and most apps don’t account for it.
The Atmospheric Column UV Travels Through
UV radiation gets attenuated as it passes through the atmosphere — primarily by ozone in the stratosphere, and by water vapor, aerosols, and clouds lower down. The common assumption is that cloud cover is the main dial: more cloud, less UV. That’s loosely true at sea level. At elevation it breaks down, for two reasons that are worth separating out.
First: cloud cover percentage tells you how much of the sky dome is obscured, not how optically thick those clouds are. A field of thin cirrus at 25,000 feet can register 70% cloud cover and block almost nothing in the UV band. Cirrus is nearly transparent to UV — the attenuation that actually matters is in the UV-absorbing portion of optical depth, which cirrus barely contributes to. So cloud at 70% with cirrus overhead is a very different situation from cloud at 70% with thick cumulonimbus. The API returns one number for both.
Second: at altitude, you’ve already passed above a significant fraction of the aerosol and water vapor column that would otherwise sit between a user and the sun. A hiker at 3,000 meters is above most of that lower-atmosphere attenuating layer. Even with identical cloud cover, raw UV exposure is measurably higher than at sea level — roughly 10–12% per 1,000 meters, per WHO guidance on UV and altitude, though the actual increment varies with aerosol load and ozone column thickness on the day.
What the API Actually Gives You — and What It Doesn’t
WeatherAPI returns uv_index in current conditions, hourly forecast, and daily summary. The daily value is a peak, not an average — that matters if you’re computing cumulative dose across a day rather than just flagging the worst hour. The hourly value is more useful for most alert logic.
What you don’t get is a UV index explicitly corrected for the elevation of your requested coordinate. The index reflects conditions at that location as the underlying model sees them — which includes some elevation influence through the NWP (numerical weather prediction) data — but it isn’t a documented, elevation-corrected value you can rely on as such. If you’re pulling a forecast for 47.2°N, 11.1°E, resolving to a point at 2,200m in the Austrian Alps, how well the model captures the elevation effect depends on how that grid cell is handled in the underlying GFS or ECMWF run. That’s not a WeatherAPI-specific limitation; it’s a general property of gridded model output.
If you’re serving users at variable elevations — ski resorts, hiking apps, agricultural sites in mountain valleys — apply your own altitude adjustment on top of the returned uv_index rather than treating it as a fully ground-truth value for that location.
A Simple Altitude Correction You Can Apply Client-Side
If you have the user’s elevation (from device GPS, a DEM lookup, or the elevation_m field in the API location object), a rough correction looks like this:
adjusted_uv = api_uv_index * (1 + 0.10 * (elevation_m / 1000.0))That’s a 10% uplift per 1,000 meters above sea level. It’s a linearization of something that isn’t perfectly linear, and it ignores ozone variability and aerosol load entirely. But it’s directionally correct and meaningfully better than doing nothing for locations above 1,500m. Treat it as a floor adjustment, not a precise reading.
The basis isn’t invented — both the WHO and ICNIRP publish guidance on UV altitude dependence. You’re applying documented atmospheric physics to an API output that wasn’t built to handle your specific use case out of the box.
The Cloud Cover Trap
The pattern that catches most developers: they use cloud as a proxy for UV suppression, which works reasonably well at low elevation with stratiform cloud. Then they ship to users skiing above treeline or hiking in alpine terrain, and the app flags UV as low because cloud cover is 65% — when what’s actually overhead is patchy cirrus and the UV exposure is high enough to burn unprotected skin in under 20 minutes.
You can partially guard against this by treating the combination of fields as a signal rather than either one alone. If uv_index is above 6 and cloud is above 50%, that’s consistent with high, thin cloud rather than low, optically thick cloud. A thunderstorm at 50% cover would crater the UV index. Cirrus at 50% cover won’t. Neither field tells you that by itself.
Another useful cross-check: compare uv_index against hour of day and is_day. UV above 7 at solar noon in summer is physically plausible even with moderate cloud cover. UV above 7 at 4pm in November at mid-latitudes is worth logging as suspicious — either the data is off, or something unusual is happening with the ozone column that day. It happens, but not in a way most API forecast runs would reliably catch.
What This Means for Alert Thresholds
The WHO UV index scale puts 6–7 as “high”, 8–10 as “very high”, and 11+ as “extreme”. Those thresholds were developed for average conditions at low-to-moderate elevation. At 2,500m, a raw API reading of 7 is functionally closer to 9 once altitude is factored in.
If you’re building alerts for hiking, ski, or mountaineering apps without adjusting for elevation, your “high UV” threshold is miscalibrated for your actual user context. That’s not a criticism of the API — it’s what happens when sea-level-calibrated thresholds get applied to altitude use cases without adjustment.
When we built out a rough outdoor advisory layer that stacks UV, temperature, humidity, and wind into a composite score, UV altitude adjustment was one of the first domain-specific corrections we had to add. The raw index was consistently under-flagging risk for elevated locations. Above 2,000m, the gap isn’t subtle.
One Caveat Worth Naming
None of this accounts for surface reflectance. Reflected UV from fresh snow can nearly double effective exposure — the WHO puts snow albedo at up to 80% UV reflectivity versus 5–10% for grass. The API gives you snow_cm in the daily data. If you’re building for ski or winter alpine use cases, snow cover on the ground is at least as important an amplifier as altitude, and it’s entirely absent from the uv_index value you’re getting back.
The right frame for uv_index from any weather API: it’s an estimate of above-ground, unobstructed exposure as modeled at that coordinate. Everything about the user’s actual context — altitude, surface reflectance, canyon versus exposed ridge — is yours to layer on top of that base.
If your app serves users anywhere above 1,500m: pull the elevation field, apply a correction, and cross-check against the combination of UV index and cloud cover rather than cloud percentage alone. The raw number isn’t wrong. It’s just not built for where your users actually are.