How to pace an ultra trail race

The planner does not use one pace for the whole race. It works out the time for each part of the route from its grade, then adds fatigue, altitude, surface and darkness. You set a flat pace or a finish time, and it solves for the other.

Why one average pace is not enough

A climb costs more time than the matching descent gives back. A plan that splits the race into equal blocks of distance will be too fast on the climbs, too slow on the descents, and late at the aid stations.

The error does not stay local. A plan that is a little too fast on a long climb puts the arrival minutes too early, and those minutes can decide a cutoff or a crew meet. A plan is useful before race day because it shows where that pressure falls, not because it predicts the finish to the minute.

The model used here is empirical. It was checked against recorded races, and its descent branch is deliberately cautious: the fastest descending is around -8% grade, and past about -16% a descent is priced slower than flat ground. Steep descents are treated as a cost, not free speed. A model that treated them as free speed would make steep descents look faster than the recorded races did.

The treadmill curve in Minetti et al. (“Energy cost of walking and running at extreme uphill and downhill slopes”, Journal of Applied Physiology, 2002) rewards steep descents much more than the recorded races did; against those records it over-predicted descent speed by up to about 2×. That shape does not describe trail pace, so this model does not use it.

What the model does, in order

Point by point, not average grade

Cost rises faster on climbs than it falls on descents, so a rolling leg is not the same as its average grade. A leg with equal climbing and descending can average close to flat and still cost more. The planner prices each point of the route and adds up the result. On the routes used to check the model, pricing by average grade under-priced rolling terrain by 4–7%.

Fatigue has a shape

The model starts with a slowdown rate per hour of running and can flatten at a ceiling. A new profile starts at 5% per hour, flattening at 40%. Both values are editable. A straight line would assume the same slowdown every hour and no limit; the ceiling stops the estimate once the slowdown reaches it. The rate uses running time, not elapsed time, so time spent at an aid station does not add fatigue.

Altitude, surface and darkness

Altitude adds a penalty above a threshold, 2,500 m by default. Surface uses easy, trail or technical factors. Darkness is decided at the midpoint of each segment from the race start and the route's location. All three are editable because they vary by runner and by route.

They are kept as separate costs because each changes speed without changing the grade. Altitude applies above the threshold, surface applies to the section it covers, and darkness follows the clock and the route's location. A change to one does not silently change the others, and the plan can mark the sections where they apply.

Setting a finish time

You can enter a flat pace or a target finish time. In target-time mode, the planner re-solves the whole model until the finish time lands on your target. The result includes aid-station time, fatigue, altitude, surface and darkness.

A target is often set by a cutoff, a crew meet or the last train. Dividing the target by the distance would ignore the course; solving through the full model makes the climbs, stops and fatigue part of the target rather than averaging them away.

An example plan

This example uses Swiss Alps 100 km from the library: 98.8 km, 6,094 m of climbing, 12 stations and the cutoffs in the race entry. It is a 24:00 target finish with an example profile: 5% per hour of fatigue flattening at 40%, 10% night and altitude penalties, 1.00 climb and descent scalers, 5 minutes at aid stations and 15 minutes at the Binn drop bag. The planner solves a flat pace of 8:21/km. The race starts at 17:30 local; times below are elapsed.

Total time: 24:01 (23:01 running and 60 minutes at stations). The target was 24:00; the solver lands one minute over. Every cutoff has room: the tightest buffer is 0:48 at Kühboden.

The table also shows which cutoff is actually tight. Here the first one at Kühboden has 48 minutes of room; the later cutoffs have more. A finish time on its own would not show that the first 6.5 km, not the end of the race, is where the plan has the least margin.

Swiss Alps 100 is the organiser's event; see the organiser's site. UltraTrailPlan is not affiliated with it. This is an example plan computed from the public route and aid-station data, not an official plan.

A different target, profile or route gives different numbers. The point of the example is the shape of the output: each station has an arrival and a departure, and the total includes both running and station time.

What this model does not claim

It is an empirical model, not a laboratory measurement. The result depends on the route, the elevation data and the values you enter. Weather, heat, mud, sleep and stomach problems are not in the model. Use the plan as a starting point, and check it against your own experience and the race's rules.

Cite this page: “How to pace an ultra trail race”, UltraTrailPlan, https://ultratrailplan.com/guides/how-to-pace-an-ultra-trail-race/.