Anatomy of a good day: reading the fields together

A `/v1/site` response is a couple of dozen fields, and the most common question I get from people building on the API is a reasonable one: which ones do I actually look at? So rather than another single-field explainer, this is a walk through a whole forecast point on a good day, in the order you would actually read it, and how the fields lean on each other.

Start with `day_rating`. On our representative good day it comes back `good`. That is the triage field - it exists so you can scan a list of sites and know which ones are worth a closer look without reading every number. But it is a label, not a measurement, and the rest of this post is what is underneath it.

Next, the two fields that carry most of the day. `wstar_ms` at 2.5 means the convective boundary layer is mixing with a velocity scale of 2.5 m/s - which, as the wstar explainer covers, is not your climb rate but the scale of the whole overturning; the good cores inside it will run noticeably stronger. And `hglider_agl_m` at 1800 m is the working height - the glider-capped ceiling, already corrected for cloudbase and the weak top of the layer. Strong-ish thermals and a properly high ceiling: that is the backbone of a real cross-country day.

Then cloudbase, which comes in two flavours for a reason. `cloudbase_agl_ft` is what most pilots think in - feet above the ground. `cloudbase_msl_m` is the absolute altitude, and it is the one that matters the moment launch elevations vary, which they do across most of the countries we cover. On a flat UK day the AGL number is enough; planning a transition between a valley and a ridge, you want the MSL one.

Now the field that turns a good day into a memorable one: `horizontal_convergence_s1`. If there is a convergence line within reach, the day stops being about finding the next thermal and starts being about staying on the line. On our example day it is sitting around 2e-4 over part of the route - a real, flyable line. That is the field a general weather app cannot give you, and the convergence explainer has the numbers for reading it.

Here is the part worth understanding if you are building anything that displays the rating: how `day_rating` is actually computed. The internal score is five times a weighted sum - 35 percent thermal strength (`wstar_ms` measured against 2.5), 35 percent ceiling (`hglider_agl_m` against 1800 m), 15 percent thermal efficiency (the buoyancy-to-shear ratio, `wstar_ms` over the low-level shear), and 15 percent convergence - and then it subtracts penalties for boundary-layer cloud and for rain. The label bands are simple: below 1 is poor, 1 to 2 marginal, 2 to 3 fair, 3 to 4 good, 4 and up excellent. The consequence is the thing people miss: a day with genuinely strong thermals can still come back only `fair` if cloud is suppressing the heating or rain is clipping the window. The penalty terms are real, and they are why the label sometimes disagrees with the headline `wstar_ms`.

What the label deliberately does not tell you: timing (a day can be `good` for four hours and `excellent` for forty minutes - use the hourly values), spatial variation (the rating is for one 4 km cell, and the next valley can differ), and confidence (a shaky `good` and a rock-solid one come back identical). Which is the whole argument of this post: never show `day_rating` alone. Pair it with at least `wstar_ms` and `cloudbase_agl_ft`, and the day stops being a word and becomes a shape. Full field list on the API reference.