Running Pace Adjustment for Heat and Humidity (°C and °F)

Add the air temperature to the dew point — both in the same unit — and read the sum against a band table. Below a sum of 20 °C (100 °F) the common charts tell you to change nothing. By a sum of 50 °C (154 °F) you are in the four-and-a-half to six percent range, which on a three-hour marathon is eight to eleven minutes of finish time.

That is the whole method. What follows is the part the calculators skip: converting those sums to Celsius without introducing a 17.8-degree error, turning percentages into clock times you can print, and replacing the generic band with a coefficient measured from your own runs.

Why the sum keys off dew point, not humidity

Relative humidity tells you how close the air sits to saturation *at its current temperature*. Change the temperature and the same percentage describes a different day. Dew point moves only when the actual moisture content of the air moves, which is why the widely circulated pacing tables are built on temperature-plus-dew-point rather than temperature-plus-humidity.

Is 70% humidity high for running?

Unanswerable without the temperature. Here is one 70% reading at three air temperatures, with dew points from the Magnus approximation:

Same number on the weather app, three different races. If you want to reproduce the middle column: `Td = 243.04 × γ / (17.625 − γ)`, where `γ = ln(RH/100) + 17.625·T / (243.04 + T)` and T is in °C.

The practical consequence is that a humidity percentage is close to useless as a pacing input on its own. A muggy 70% at dawn in October and a punishing 70% at 28 °C differ by more than 15 °C of dew point.

The Celsius bands, and the 17.8-degree conversion trap

Almost every published sum table is in Fahrenheit, and runners outside the US convert it wrong. You cannot take a Fahrenheit *sum* and run it through `(F − 32) / 1.8`, because adding two Fahrenheit temperatures adds the 32-degree offset twice.

The correct conversion for a sum is:

sum°C = (sum°F − 64) / 1.8

Take a 28 °C / 22 °C day. In Fahrenheit that is 82.4 + 71.6 = 154. Convert it naively and you get 67.8 °C; convert it properly and you get 50.0 °C. The error is 17.8 °C every single time — exactly 32/1.8 — and it will push you two or three bands too far.

Above a sum of roughly 64 °C (180 °F) the charts stop offering a percentage and advise against hard running altogether. Read that as a session-design question rather than a pacing question, and check what the event itself publishes for hot-weather starts.

Treat the percentages as a starting range rather than a measurement. Their value is that they give you a defensible number before the gun goes off; the calibration step below is what turns that number into yours. If you would rather have the arithmetic done for you, the walkthrough in our heat adjusted pace calculator guide covers the same inputs.

What a percentage costs in minutes

Percentages are unpersuasive until you convert them. Here is a 3:00:00 marathon — 4:16/km, 6:52/mile — at each band:

The scaling rule is trivial and worth memorising: one percent is one percent of your goal time. That is 1:48 on a three-hour marathon, 2:24 on a four-hour, 3:00 on a five-hour. Multiply from there and you never need a second table.

Notice how small the per-kilometre numbers look. Fifteen seconds a kilometre feels like nothing standing on the start line, which is precisely why runners refuse to take it — and why the deficit only becomes visible as a ten-minute hole at 35 km.

Measuring your own coefficient instead of borrowing one

The band table knows nothing about you. Six runs will give you something better.

Pick one loop you run often. Collect runs where the average heart rate landed within a few beats of each other, note the temperature-plus-dew-point sum for each, and plot pace against sum. The slope is your personal penalty in percent per degree of sum.

A worked example: 5:30/km on a 20 °C sum, 5:52/km on a 34 °C sum, matched heart rate. That is 6.7% across 14 degrees, or 0.48% per °C of sum.

Now watch what happens if you trust it. Extrapolate 0.48%/°C out to a 45 °C sum and you get 12% — roughly triple what the chart says for that band. Two runs cannot separate the heat from the wind, the hydration, the cardiac drift and the fact that one of them was on tired legs. Which gives you two rules:

• Use the median of at least six paired runs, not the slope through two.
• Do not extrapolate the coefficient more than 10 °C of sum beyond your hottest measured run. Outside that range, go back to the band table.

Stacking heat on top of hills, wind and altitude

Heat is rarely the only correction. The mistake is adding the percentages: 4% for heat plus 3% for terrain is not 7%, it is 1.04 × 1.03 = 7.12%.

On a three-hour marathon that difference is about 13 seconds — irrelevant. It stops being irrelevant as the adjustments grow. At 8% heat and 10% for a climbing course, additive gives 18% and multiplicative gives 18.8%, a gap of roughly 86 seconds. Anything you plan on a mountain course in summer needs the multiplication.

The order does not matter mathematically, but the bookkeeping does: apply each factor to the *flat, cool* baseline pace once, and keep the factors separate so you can see which one you are wrong about afterwards. Our breakdown of elevation, wind and altitude adjustments covers the non-thermal side of that multiplication.

Four ways this goes wrong

Banking the first hour. A single percentage spreads the cost evenly across the race, which is an assumption, not a physical law. Plan the full adjustment from kilometre one and hold a second, larger step in reserve for the last 10 km — not the reverse.

Reading grade-adjusted pace as heat-adjusted pace. Your watch corrects for the hill. It has no dew point input at all. Two separate corrections, and neither substitutes for the other.

Double-correcting easy runs. If you already cap easy runs by feel or heart rate, the heat is enforcing itself — the slower pace is the output. Applying a chart on top of an HR cap corrects the same thing twice.

Assuming acclimatisation the chart cannot see. The table gives one band regardless of whether your last fortnight contained ten hot sessions or none. A workable default: if nothing in the past 14 days exceeded a 40 °C sum, take the top of the band rather than the middle.

A race-week sequence that produces a printable number

1. T−7: pull temperature and dew point for the *start hour*, not the daily high and not a 24-hour average. Write down both the forecast and the historical baseline for that date.
2. T−3: compute the sum for the start hour and again for your expected finish hour. On a morning marathon these usually differ by two bands.
3. T−2: convert the band into cumulative clock times, not into a pace. A pace column invites arithmetic at 30 km; a clock column does not. The mechanics are in our marathon pace band calculator guide.
4. T−1: write the fallback row *before* you are hot. Something like: "if 10 km heart rate is more than 5 bpm above plan at the adjusted pace, switch to the next band down."
5. Race morning: re-read the dew point 90 minutes out. If the sum has crossed a band boundary, use the slower row you already printed. Do not recalculate in the start pen.

Three questions worth answering

Should I use heat index instead of dew point? Heat index folds both variables into one number, which is quicker to read but hides which one moved. Either input works if you stay with it — mixing methods across a training block makes your own history uncomparable, and your history is the only calibration data you have.

Does the adjustment apply to heart rate targets too? If you are running to an HR cap, the cap is already doing the adjusting and the pace you see is the result. Choose one as primary and let the other float.

Does the table work in reverse for cold? No. Below a sum of about 20 °C the bands flatten to zero and stay there, and the cold-side penalty is dominated by wind chill, layers and footing — none of which appear in a temperature-plus-dew-point sum. Run the cold as a separate problem.