How we score the weather

Every destination on this site carries a number from 0 to 10. That number decides what you see and in what order, so you are entitled to know exactly how it is produced. Here is the whole model, including the parts that make us look bad.

What qualifies a destination

Before a destination appears on this site at all, its 7-day forecast must contain a run of at least 3 consecutive days that each pass all three checks:

• Daily high above 70°F (strictly greater than — exactly that value does not qualify)
• Maximum precipitation probability below 20% (strictly less than — exactly that value does not qualify)
• No thunderstorm WMO code (95–99) in the forecast

These are the live values read from the settings table at render time. They are not duplicated anywhere in the codebase. Preview different values before changing them.

The short version

We score each forecast day on its own, then combine the days into a score for the whole window. We do not average the week and call it a day — averaging is how a travel site turns four grey days and one good one into "sunny".

Step 1 — scoring a single day

Each day gets a 0–10 score built from three things:

• Temp (40%) — how close the day's high sits to a comfortable range. It falls off in both directions: too cold and too hot are both penalised.
• Sky (30%) — derived from the WMO weather code. Clear sky scores highest, then partly cloudy, then overcast, then fog, drizzle, rain, showers and thunderstorms.
• Dryness (30%) — from the day's maximum precipitation probability. We use the maximum, not the average, because the rain that ruins an afternoon does not care what the daily mean was.

The caps

Some conditions are bad enough that no amount of pleasant temperature should rescue the day, so we cap the result outright rather than let the weighting average it away:

• A day with a thunderstorm is capped at 4.0.
• A day at 115°F or hotter, or 45°F or colder, is capped at 5.5 — that is outside the usable range for the kind of trip we sell, whatever the sky is doing.
• Fog, drizzle, rain and showers each carry their own lower cap on top of the sky penalty they already take.

Step 2 — scoring the window

Why one great day cannot carry a week

That middle term is the whole point. A quarter of the window score is set by the worst day in it. If you fly somewhere for five days and one of those days is a washout, the washout drags the score down and stays visible in it — there is no arrangement of good days that can hide it.

The best day in a window gets no special treatment at all. It contributes only through the trimmed mean, alongside every other day. A single spectacular Tuesday does not make the week worth flying for, and the arithmetic here refuses to pretend otherwise.

Why "clear" excludes "partly cloudy"

When we say a window has three clear days, we mean three days the forecast calls clear or mainly clear. Partly cloudy days are not counted as clear. They are perfectly pleasant days and they score well — but calling them clear is the exact sleight of hand that makes weather marketing untrustworthy, so we do not do it.

We also report the count of clear days separately from the score, and never fold it in. The score answers "how good is this week overall?". The clear-day count answers "how much actual sun am I getting?". Those are different questions, and a destination can do well on the first while doing badly on the second. When that happens we show you both numbers side by side rather than the flattering one alone.

The card badge — one vocabulary

Every destination card carries a badge that describes the current window in a single phrase. That phrase is built from the same three numbers that appear elsewhere on the card: the weather score, the genuinely-clear-day count, and the peak temperature. No separate calculation is run for the badge.

Two vocabularies ran in parallel until August 2026. The label used “bright days” (clear + partly-cloudy) while the badge used “clear days” (WMO 0–1 only). That split let Destin show “no clear days” on the badge while its own label said “2 bright days” — both reading from the same underlying data. The fix: one term throughout. The badge, label, and headline now all count from the same field, so they cannot contradict each other.

Badge tier follows score order. A destination scoring 8.0 or above earns the highlighted (teal pulsing) chip. Below 8.0 it gets the muted chip. Within each tier the text tells you why: cloud fraction, wet-day count, clear-day count, and peak temperature when it clears 100°F — so Dallas at 106°F and Jackson Hole at 89°F carry visibly different badges even when their clear-day counts match.

A real worked example, from today's data

This is not an illustration. It is read live from the forecast cache that powers the rest of the site, at the moment this page loaded, and it is deliberately the most awkward case we could find in it.

If that example looks unflattering, that is because it is. It was chosen by preferring the highest-scoring destination in the cache with zero clear days, precisely so the uncomfortable case is the one on display. Publishing a scoring model and then illustrating it with your best-looking city is a brochure, not a methodology.

What this score is not

It is a forecast, and forecasts are wrong sometimes. A 9 is not a promise of sunshine and carries no entitlement to a refund if the week turns. What the score does promise is that the same published arithmetic was applied to every destination, that nothing was quietly boosted, and that when the sky is grey we say the sky is grey. The full terms are on our terms page.

Weather data from Open-Meteo. Scores recomputed on every refresh — see system status for when that last happened.

The almanac sunshine metric — a second instrument

Historical almanac pages carry a second metric alongside the WMO-code clear bar above. The two instruments answer different questions and are published side by side so you can compare before any headline change is made.

Why a second metric?

The WMO daily weather code is a worst-moment-of-the-day summary. A Lowcountry July day that is brilliantly sunny from 7am to 3pm, gets a 25-minute convective storm at 4pm, then clears again, receives code 63 (moderate rain) for the whole day. The WMO clear bar discards that day entirely.

sunshine_duration is not fooled by the storm. It records roughly 12 hours of direct sun. The new metric counts this day correctly as warm and sunny — which is what a guest who visited in July experienced.

What this measures vs. the code bar

• WMO-code clear bar — best instrument for today's forecast. A 4pm storm matters to someone flying tomorrow. Still used on forecast cards.
• Sunshine-based bar — best instrument for historical character. How many hours of sun does a typical July day contain? sunshine_duration answers this; WMO code does not.

Supporting metrics published alongside it

• % days > 8h sunshine — a stricter version of the primary bar.
• Median daily sunshine hours — the central value, not the mean, so one freak sunny week cannot inflate it.
• % days with ≥ 1mm rain — always shown, never buried. Rain is disclosed, not hidden behind the sunny numbers.

Why error size varies by climate

The WMO bias is not a constant offset that can be patched with a fudge factor. It is climate-dependent: subtropical and tropical destinations with frequent short afternoon convective storms are heavily understated (measured gap up to +84 points for Key West in August). Desert and mediterranean climates where storms are rare are nearly unaffected (San Diego July: gap < 3 points). The metric must therefore be recomputed per destination from real sunshine hours.

Importantly, bad months stay bad under the new metric: Aspen in January is 0% warm and sunny, Hilton Head in January 3%, Scottsdale in January 13%. This is what makes the good numbers credible — the metric is not indiscriminate inflation.

Sunshine metric data: ERA5 via Open-Meteo archive API (archive-api.open-meteo.com), 8 years (2018–2025). Computed by scripts/backfill_sunshine_almanac.py; refreshed monthly. Machine-readable definition: DefinedTerm JSON-LD embedded in this page.

How destinations are added and removed

The roster is self-maintaining. A place is added because it demonstrably qualifies and removed when it stops. No human decides which places are destinations. The rule is stored in the database and published here verbatim — it is the same rule the nightly discovery loop applies.

Promotion test (all three must be true)

• Price spread (p90 − p10) ≥ $100 — a wide spread means both budget and luxury inventory exist, the hallmark of a leisure market. Pure business corridors with commodity hotels have narrow spreads.
• Hotel count ≥ 2 — at least 2 hotel options (floor, not filter). This floor rejects airports with zero inventory without failing legitimate low-count leisure destinations like Nantucket (11 hotels) or Kauai (8 hotels), both of which beat Chicago (146 hotels) on price spread.
• Max star rating ≥ 3.5 — at least one mid-to-upper-tier property. Discriminates leisure from business transit (Bloomington, IL: 3.0☆ max).

Hysteresis

A candidate must pass the test on 2 consecutive daily checks before it is added to the roster. An active destination must fail on 3 consecutive daily checks before it is removed. This prevents a single API error or transient supply gap from reshaping the roster.

Blast-radius caps

At most 5 destinations can be added and at most 5 can be removed in a single nightly run. A loop that can add 80 or delete 30 at once is a liability, not a feature.

Retired destinations

A retired destination’s URL returns HTTP 410 Gone rather than silently 404-ing. This signals to search engines that the page existed and was intentionally removed, rather than disappeared without notice. The page carries a noindex directive.

Rule derived from Phase B distribution analysis (141 US airports screened 2026-08-07). Rule effective: 2026-08-08. Screening cadence: every 90 days per candidate.