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 article runs all three for a 4-hour marathon target and shows how their outputs combine into one coherent race plan.

Scenario inputs

target_distance_km:     42.195
target_time_min:        240   (4:00:00 marathon)
total_elevation_gain:   250m  (rolling course)
total_elevation_loss:   250m

Engine outputs

Running Pace Calculator (flat baseline)

paceMinPerKm:        5.69 (5:41/km)
paceMinPerMile:      9.15 (9:09/mile)
projectedRaces:
  5K:               28:26 at this pace
  10K:              56:53
  Half:             2:00:00
  Marathon:         4:00:00 (input)

240 minutes / 42.195 km = 5.6878 min/km = 5:41.3/km. The engine returns the same baseline pace as a "what does this average translate to" tool, useful for training-pace anchoring.^[4]

Marathon Pace Elevation (rolling course)

targetDistanceKm:                         42.195
targetTimeMinutes:                        240
averagePaceSecondsPerKm:                  341 (5:41/km)
flatEquivalentPaceSecondsPerKm:           340 (5:40/km)
netElevationCorrectionSeconds:            38 (total, across the marathon)
difficulty:                               flat

For a course with equal gain and loss (250m each), the net gradient is zero, so the engine classifies the course as "flat". It still applies a small total correction of 38 seconds over the full marathon (about 1 s/km), because Minetti et al. quantified that uphill costs more energy per metre of elevation than downhill returns — producing a small net penalty even when total ascent equals total descent.^[1]

Race Time Predictor (cross-distance)

predictions (from the 4:00:00 marathon as the known input):
  5K:               25:01
  10K:              52:10
  Half:             1:55:07
  Marathon:         4:00:00

The race predictor uses Riegel's exponent (1.06 default) and produces 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                   38 s   (≈1 s/km)
500 / 500         0.0 m/km       flat                   75 s   (≈2 s/km)
500 / 200         7.1 m/km       rolling                120 s  (≈3 s/km)
1000 / 400        14.2 m/km      climbing               240 s  (≈5 s/km)
1000 / 1000       0.0 m/km       flat                   150 s  (≈3 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 150-second total correction from the uphill/downhill asymmetry. Second, the per-kilometre corrections are modest — 1 to 5 s/km across the realistic range — far smaller than the double-digit-per-km penalties often quoted in pacing folklore.

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 reading: Marathon Pace Elevation Validated for the slope-correction empirical validation, Race Time Prediction: Riegel Limits for the Riegel-formula failure modes, and How To Train For A 5K for 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]

References

1. 1 Energy cost of walking and running at extreme uphill and downhill slopes (Minetti et al.) — Journal of Applied Physiology (2002)
2. 2 Effects of slope on metabolic cost of running and pacing strategies — Journal of Sports Sciences (2014)
3. 3 Athletic records and human endurance (Riegel) — American Scientist (PubMed PMID 7235349) (1981)
4. 4 Methodology notes for the Running Pace Calculator — AI Fit Hub (2026)