Cloud cover percentage sounds like a simple field. It’s not. It’s a sky-fraction estimate — roughly what portion of the celestial dome above a point is obscured by cloud. That’s useful for solar irradiance calculations and general daytime-darkness estimates. It’s nearly useless for telling you whether a mountain location is sitting inside a cloud, above one, or below a solid overcast ceiling.
This distinction comes up constantly when developers try to use cloud values from forecast APIs to drive visibility logic for hiking apps, ski resort dashboards, or anything where terrain height matters. The complaint usually arrives framed as “your cloud cover data is wrong” — but the actual problem is almost always a category error: using a sky-fraction field to answer a question about ceiling height.
What total cloud cover is actually measuring
The field we expose — and that most weather APIs expose — is derived from model output that estimates cloud fraction at various pressure levels (low, mid, high) and combines them into a single total. GFS does this across roughly a dozen sigma levels. HRRR, with its 3km horizontal grid, resolves cloud structure better horizontally but still bins it vertically in ways that collapse into a single percentage for a given point.
The result tells you something like: 75% of the sky above this coordinate is covered by cloud of any altitude. It doesn’t tell you whether that cloud is thin cirrus at 8,000 meters or a stratus layer with a base at 600 meters. For a location at sea level, that ambiguity rarely matters. For a location at 1,400 meters — a ski resort base, a summit weather station, a mountain hut — it matters enormously.
If the stratus base is at 900 meters, a 1,400-meter location is sitting inside it. The cloud cover field might show 85%. But so would the same stratus viewed from a valley floor at 200 meters, where the observer is 700 meters below that base, looking up through clear air at solid overcast. Same percentage, completely different physical reality.
Why elevation compounds this in non-obvious ways
The lapse-rate correction we apply to temperature (roughly 6.5°C per 1,000m, per the ICAO standard atmosphere) has an analogue in cloud behavior: cloud base height is directly tied to the lifted condensation level (LCL), which is a function of surface temperature and dewpoint spread. As you gain elevation, you’re physically approaching or entering the cloud layer that someone in the valley is looking up at from below.
Model grids don’t fully resolve this for individual mountain points. A GFS grid cell covering mountainous terrain represents some average of the topography inside it — often a smoothed elevation well below the actual peak or ridge. When the model reports cloud fraction for that cell, it’s describing the sky above an elevation that may sit several hundred meters below your actual location. A ski resort at 2,100 meters in a GFS cell whose mean orographic elevation is 1,600 meters will routinely get cloud fraction values that describe a sky above a point that’s materially lower than where the resort actually is.
HRRR’s 3km grid reduces this by resolving terrain better, but it doesn’t eliminate it — and HRRR doesn’t cover the whole world anyway.
What you can actually derive — and what requires aviation data
Cloud cover percentage combined with a cloud base height estimate is more useful than cloud cover alone. METAR observations include ceiling height directly — encoded as BKN or OVC layers with heights in hundreds of feet AGL. A raw METAR from a station near your location will give you something like OVC012, meaning overcast at 1,200 feet above ground level. That, combined with the station’s elevation, gives you an actual ceiling altitude you can compare against a mountain location’s elevation.
Our condition code mapping captures broad states like “overcast” and “mist” but deliberately doesn’t encode ceiling AGL — that would require attaching METAR ceiling data to every response, which we don’t currently do. If ceiling height is genuinely critical for your use case, you need either raw METAR access (NOAA’s aviationweather.gov provides parsed METARs at no cost) or a dedicated aviation weather endpoint. For most non-aviation apps, there’s a workable middle path.
A practical approach for mountain-aware cloud logic
What we’d actually recommend for a terrain-aware app:
- Pull
cloud(total cover percentage),temp_c, anddewpoint_cfrom the hourly forecast for your location. - Compute the LCL approximation: LCL height (meters) ≈ 125 × (temp_c − dewpoint_c). NWS forecasters use this as a rough cloud base estimate for convective analysis. It’s not precise for stratiform cloud, but it’s directionally correct and easy to compute.
- Compare that LCL estimate against your location’s elevation. If the LCL height above the nearest surface station is less than the elevation difference between that station and your target point, your point is likely inside or above the base of the cloud layer when cover is high.
- Flag the combined condition — not just “overcast” but “overcast and in-cloud” — and adjust your visibility and usability logic accordingly.
This is not a precise ceiling detector. The LCL approximation was designed for convective cloud base, not stratus, and real-world cloud base varies with local geography and airflow in ways a point formula can’t capture. But it’s a substantially better signal than treating 85% cloud cover identically regardless of elevation.
Where cloud fraction data is actually reliable
Flat terrain, near sea level, with good station density: cloud fraction works well. It’s a solid input for solar energy yield estimates, general overcast/clear classification, and daytime brightness prediction. The field does exactly what it says.
The failure mode is specific: mountainous locations, high-elevation points, and any situation where the real question is “is this location above or below the cloud base” rather than “how much of the sky is covered.” Those are different questions, and the field answers the second one reliably and the first one only approximately.
One more wrinkle: high-altitude thin cloud — cirrus above roughly 6,000 meters — can push cloud cover percentage into high territory while having zero effect on surface visibility. A location showing 60% cover that’s entirely cirrus is effectively clear-sky for all practical ground-level purposes. The percentage alone doesn’t tell you which layers are contributing.
The honest limitation
No weather API field currently solves this cleanly without explicit ceiling data from METAR or a dedicated nowcast layer. Vertical cloud structure is genuinely hard to expose through a single percentage, and the industry-wide choice to report total cloud fraction as the primary field reflects model output structure more than it reflects what developers building terrain-aware apps actually need.
If you’re building for mountain locations, treat cloud as one input among several and compute the LCL estimate alongside it. And if you ever see 100% cloud cover alongside high visibility and mild conditions, it’s almost certainly cirrus — a maxed-out cover field doesn’t mean the ground is socked in.
Pull the dewpoint spread alongside cloud cover for your mountain locations and check how often the LCL estimate falls below your target elevation on days you know were foggy. That comparison will tell you faster than anything else whether this is actually affecting your use case.