Running Pace vs Marathon Pace-Elevation: Flat vs Hilly Targets

Three running tools, three different jobs. The Running Pace calculator handles steady-state pace planning; Marathon Pace Elevation adjusts for slope; the Race Time Predictor extrapolates across distances. This is the decision-frame entry in the marathon-pacing track of our race-prediction series: it runs all three for a 4-hour marathon target and shows how their outputs combine into one coherent race plan.

Engine outputs

A 4:00:00 marathon target (42.195 km in 240 min) through the Running Pace Calculator, the Marathon Pace Elevation tool on a rolling 250 m-gain / 250 m-loss course, and the Race Time Predictor taking the marathon time as its known input:

# running-pace-calculator (computed live from /engines/running-pace-calculator.js)
Engine input
  distance_km           = 42.195
  time_minutes          = 240

Engine output
  paceMinPerKm          = 5.6878777106292215
  paceMinPerMile        = 9.153751866334874
  projectedRaces[0].label= 5K
  projectedRaces[0].distanceKm= 5
  projectedRaces[0].timeMinutes= 28.43938855314611
  projectedRaces[1].label= 10K
  projectedRaces[1].distanceKm= 10
  projectedRaces[1].timeMinutes= 56.87877710629222
  projectedRaces[2].label= Half Marathon
  projectedRaces[2].distanceKm= 21.0975
  projectedRaces[2].timeMinutes= 120
  projectedRaces[3].label= Marathon
  projectedRaces[3].distanceKm= 42.195
  projectedRaces[3].timeMinutes= 240

# marathon-pace-elevation (computed live from /engines/marathon-pace-elevation.js)
Engine input
  target_distance_km    = 42.195
  target_time_minutes   = 240
  total_elevation_gain_m= 250
  total_elevation_loss_m= 250

Engine output
  targetDistanceKm      = 42.195
  targetTimeMinutes     = 240
  averagePaceSecondsPerKm= 341
  averagePaceLabel      = 5:41
  flatEquivalentPaceSecondsPerKm= 337
  flatEquivalentPaceLabel= 5:37
  netElevationCorrectionSeconds= 188
  segments (43 items)   = [...]
  difficulty            = flat

# race-time-predictor (computed live from /engines/race-time-predictor.js)
Engine input
  known_distance_km     = 42.195
  known_time_minutes    = 240

Engine output
  predictions[0].label  = 5K
  predictions[0].distanceKm= 5
  predictions[0].timeMinutes= 25.02319703558183
  predictions[0].paceMinPerKm= 5.0046394071163665
  predictions[0].paceMinPerMile= 8.054186402006282
  predictions[0].difficultyDelta= 0.8798781657636462
  predictions[1].label  = 10K
  predictions[1].distanceKm= 10
  predictions[1].timeMinutes= 52.17165227275022
  predictions[1].paceMinPerKm= 5.217165227275022
  predictions[1].paceMinPerMile= 8.396213555523694
  predictions[1].difficultyDelta= 0.9172428615202899
  predictions[2].label  = Half Marathon
  predictions[2].distanceKm= 21.0975
  predictions[2].timeMinutes= 115.11169431903173
  predictions[2].paceMinPerKm= 5.456177002916541
  predictions[2].paceMinPerMile= 8.78086572258172
  predictions[2].difficultyDelta= 0.9592641193252643
  predictions[3].label  = Marathon
  predictions[3].distanceKm= 42.195
  predictions[3].timeMinutes= 240
  predictions[3].paceMinPerKm= 5.6878777106292215
  predictions[3].paceMinPerMile= 9.153751866334874
  predictions[3].difficultyDelta= 1
  baselinePaceMinPerKm  = 5.6878777106292215
  baselinePaceMinPerMile= 9.153751866334874

240 minutes / 42.195 km = 5.6878 min/km = 5:41.3/km, with the straight-average projections of 28:26 for 5K, 56:53 for 10K, and 2:00:00 for the half. The Running Pace tool returns the same baseline pace as a "what does this average translate to" tool, useful for training-pace anchoring.^[4]

For a course with equal gain and loss (250m each), the net gradient is zero, so the elevation engine classifies the course as "flat". It returns an average pace of 5:41/km, a flat-equivalent of 5:37/km, and still applies a total correction of 188 seconds over the full marathon (about 4 s/km), because uphill costs about twice the finish-time per metre that downhill gives back — the 2:1 asymmetry Minetti et al. quantified — producing a net penalty even when total ascent equals total descent.^[1]

Taking the 4:00:00 marathon as the known input, the race predictor uses Riegel's exponent (1.06 default) and returns 25:01 for 5K, 52:10 for 10K, and 1:55:07 for the half — faster mid-distance equivalents than the running pace tool's straight-average projections, because mid-distance races are run at higher intensity than marathon pace.^[3]

Reading the outputs

Running Pace

The Running Pace tool's strength is the steady-state "what pace do I need to hold?" answer. The 5:41/km baseline becomes the GPS-watch target for the marathon itself. Its weakness is that the projected race times for shorter distances are mechanically wrong — they assume marathon pace is sustainable for 5K, which is far too conservative.

Marathon Pace Elevation

The strength is course-specific pace planning. For the equal-gain-and-loss scenario, the ≈1-second-per-kilometre correction is small enough to absorb in standard race-day variation. For net-uphill courses the correction grows: a 1000m-gain / 400m-loss course (net +14 m/km, the engine's "climbing" class) carries a 240-second total correction, about 5 s/km.^[2]

Race Time Predictor

The race-time predictor's strength is cross-distance extrapolation. The realistic 5K equivalent (25:01) for a 4-hour marathoner is over 3 minutes faster than the marathon-pace-extrapolated 28:26. Confusing these two numbers is the most common pace-planning mistake.

Where they disagree

Three disagreement patterns worth knowing:

1. 5K race time: Running Pace (steady-state extrapolation) says 28:26. Race Time Predictor (fatigue-adjusted) says 25:01. The race predictor is correct for actual race effort; the running-pace number assumes you only run at marathon intensity.
2. Course-specific pacing: Running Pace gives one number for all courses; Marathon Pace Elevation gives an elevation-corrected number. For a hilly target race, the elevation-corrected number is the right race-day anchor.
3. Training paces: Neither the Running Pace nor the Race Predictor engines produce explicit training-zone bands. The Run Training Paces tool fills this gap.

When to use which

1. Setting a target pace for a known marathon time: Running Pace, for the steady-state per-km target.
2. Adjusting that target for a known course profile: Marathon Pace Elevation. Input the gain and loss; get the corrected average pace.
3. Predicting your other-distance times from a known marathon time: Race Time Predictor. The Riegel-derived predictions are realistic.
4. Building training intensities from the target marathon pace: Run Training Paces (VDOT-style bands).

Reading the elevation math

Minetti's published energy-cost curve quantifies the asymmetry between uphill and downhill running. Uphill running at +5% grade costs roughly 65% more energy per metre than flat. Downhill running at −5% grade saves only 25% — gravity assists the speed but the eccentric muscle loading and braking work absorb most of the gain. Net effect on a rolling course is positive energy cost compared to a perfectly flat course of equal length.^[1]

Practical numbers for a 4-hour marathon target:

Gain / Loss (m)   Net gradient   Engine "difficulty"   Net correction (total)
──────────────────────────────────────────────────────────────────────────────
0 / 0             0.0 m/km       flat                   0 s
250 / 250         0.0 m/km       flat                   188 s  (≈4 s/km)
500 / 500         0.0 m/km       flat                   375 s  (≈9 s/km)
500 / 200         7.1 m/km       rolling                600 s  (≈14 s/km)
1000 / 400        14.2 m/km      climbing               1200 s (≈28 s/km)
1000 / 1000       0.0 m/km       flat                   750 s  (≈18 s/km)

Two things stand out in the real engine output. First, the "difficulty" label keys on the net gradient (gain minus loss over distance), so a course with 1000 m of climbing matched by 1000 m of descent is still labelled "flat" even though it carries a 750-second total correction from the uphill/downhill asymmetry. Second, the corrections scale steeply with total climbing — from about 4 s/km on a gently rolling course to nearly 30 s/km on a 1000 m-climb marathon — because each metre of climb costs about 1.5 s of finish time while each metre of descent gives back only half that.

How the three engines integrate into a race plan

A concrete 16-week marathon prep using all three engines:

1. Weeks 1–4 (base): Use the Race Time Predictor to confirm the 4-hour target is realistic given the current 10K time. If current 10K is 50:00, predictor agrees; if 56:00, target needs to slide.
2. Weeks 5–10 (build): Use Run Training Paces (VDOT-equivalent) to set Easy, Marathon, Threshold, and Interval zones. Most weekly volume in Easy; one Marathon-pace session weekly.
3. Weeks 11–13 (peak): Race-pace long runs at the 5:41/km Running Pace target. Test the pace under fatigue.
4. Weeks 14–15 (taper): Use Marathon Pace Elevation with the actual course profile to set race-day per-km targets. Adjust the pacing strategy for any uphill clusters.
5. Race week: Lock the per-km bands. The first 5K should be 5–10 s/km slower than goal pace; settle into goal pace by 10K; defend in the final 10K.

The three engines combine cleanly because they answer non-overlapping questions: "is this realistic?" (predictor), "what pace?" (running pace), "course-adjusted what pace?" (elevation tool). Each layer assumes the previous one is settled.

Cross-checking against related tools

The Running Pace Calculator exposes the bidirectional pace-time-distance math. The Marathon Pace Elevation tool handles slope corrections via Minetti's curve. The Race Time Predictor exposes the Riegel exponent. The Run Training Paces Calculator converts the marathon goal into Easy / Marathon / Threshold / Interval / Reps training-zone bands.

Related in this series

• Marathon Pace Elevation — the elevation pillar: empirical validation of the slope correction.
• Net-Downhill Marathon Pacing: A Boston Case — worked case on why "net zero" elevation still costs time.
• Race Time Prediction: Riegel and Its Limits — the prediction pillar behind the flat-course baseline.
• The Marathon Taper — the execution track: the final-weeks volume curve.

Beyond the series: How To Train For A 5K covers the corresponding shorter-distance pacing.

FAQ

If I train at 5:41/km, can I actually hold it for 42 km on race day?

Only if your training included long runs at or near that pace. The published marathon-race literature finds successful sub-4-hour marathons typically include at least three 30+ km long runs with 15–20 km at goal pace inside them. Running-pace math is necessary but not sufficient; the long-run physiology has to be there.

How do I know if my course is "rolling" or "hilly"?

The engine keys its label on the net gradient — (gain − loss) divided by course length in km. Its bands are: ≤2 m/km "flat", ≤8 m/km "rolling", ≤15 m/km "climbing", above that "extreme", and below −5 m/km "downhill_aided". Note this is net, not total: a course with large but balanced gain and loss still reads "flat" even though it carries a real correction.^[2]

Does downhill running really not save much time?

Correct. The biomechanical cost of eccentric braking (especially on grades steeper than 3–4%) approaches the metabolic cost of flat-pace running. Steep downhills also produce delayed-onset muscle soreness that costs more in the final 10K of a marathon than the early pace savings gain. Net Boston-style courses have famously punishing final miles.^[1]

Why does the Race Time Predictor show faster shorter-distance times than the Running Pace tool?

The Race Predictor uses Riegel's fatigue exponent, which correctly accounts for the fact that mid-distance races are run at higher intensity than marathons. The Running Pace tool's projections assume the same pace applies to every distance, which is mechanically true but practically misleading for race-prediction purposes.^[3]