Triathlon Pace Calculator

What the triathlon pace calculator adds together

The calculator converts one swim pace, one bike speed, one run pace, and two transition estimates into a split-by-split finish-time scenario. Select one of its built-in distance profiles, enter swim minutes and seconds per 100 metres, bike speed in kilometres per hour, run minutes and seconds per kilometre, and T1 and T2 in minutes. The result is arithmetic based on constant inputs: swim distance divided by pace, bike distance divided by speed, run distance multiplied by pace, plus both transitions.

That makes the page useful for checking units and seeing how a set of assumptions combines. It does not infer your pacing from recent race results, predict how you will respond to open water or hills, estimate aid-station time, or model slowing late in a long race. Its finish time is a scenario, not a forecast distribution. The built-in course distances are example profiles. If your event’s official distance differs, use the result as a rough comparison and account for the actual route separately.

Enter pace in the unit the field expects

For swimming, enter a positive minutes:seconds pace per 100 metres. A value such as 2:05 means two minutes and five seconds for each 100 m, not a total swim time. For running, use the same minutes:seconds format per kilometre. Seconds must be between 00 and 59. A pace written as 5:60 is not valid; convert it to 6:00. For cycling, use average speed in km/h, not pace per kilometre, power, or miles per hour. Convert miles per hour to kilometres per hour before entering a value if needed.

The page checks that swim and run pace can be parsed, bike speed is greater than zero, and transition times are non-negative. It cannot verify that your number came from a representative effort. Use a sustainable training segment or a recent comparable race split rather than a short best effort. If you select an event profile, compare each leg with the organiser’s current course distance and note whether timing includes a long run to or from transition.

Follow one example from pace to total

Imagine the selected profile uses a 750 m swim, 20 km bike, and 5 km run. With a swim pace of 2:00 per 100 m, the arithmetic gives 15 minutes for the swim. A bike speed of 30 km/h gives 40 minutes for 20 km. A run pace of 5:30 per km gives 27 minutes 30 seconds for 5 km. If the transition inputs are 3 and 2 minutes, the summed scenario is 87 minutes 30 seconds. Every split in this example follows directly from the units entered; there is no adjustment for exertion, turns, traffic, or course shape.

Change one input at a time to see which assumption drives the total. For example, raising the bike time by 10 minutes while leaving the other fields unchanged reveals the direct effect of a slower cycling scenario. Then build a second case with a conservative run pace or longer transitions. Do not treat the difference between two hand-chosen scenarios as a statistical confidence interval. It simply shows what happens under those particular inputs.

Why a race split may differ from this estimate

Pool pace does not automatically transfer to open water. Navigation, starts, drafting rules, chop, current, visibility, and the route to the timing mat can change the swim split. Cycling speed changes with elevation, road surface, wind, temperature, traffic management, equipment, and how much effort you can sustain without compromising the run. Running pace can change with terrain, heat, crowding, aid stations, and fatigue. Transition timing depends on layout, distance between timing lines, bag collection, and the organizer’s process.

The calculator also assumes a single average pace for each discipline. Real pacing fluctuates. An even pace on a flat course can hide large changes on climbs and descents; an average bike speed can be hard to compare across different routes. It is not necessary to force more precision into the fields than your evidence supports. Mark unknown inputs, use a range of plausible cases, and avoid using a fast result as a reason to ignore course cutoffs or personal safety.

Turn the total into a useful rehearsal

Once the split scenario is believable, compare it with the event’s official cutoffs and checkpoint timing, including the difference between elapsed time and clock time. Add any neutralization or special event timing rules from the guide. Practice transitions in the equipment you will race with, and test the run pace after bike sessions so the assumed effort is not based solely on fresh legs. If the scenario only works with every segment near a personal best, create a slower case before building a plan around it.

Use the finish-time predictor when your question is how longer-distance estimates change under explicit slowdown assumptions. The transition-time estimator lets you inspect a separate transition scenario, and the race-day simulator can place approximate splits into a day schedule. Compare cycling power assumptions with the FTP calculator when a power-based plan is involved. The next useful action is to verify the course and practise the effort—not to treat the finish-time display as a promise.

Build scenarios that are useful under uncertainty

Start with a central case from recent, comparable training rather than an ideal effort. Then make a conservative version by changing only inputs for which a slower result is plausible: a more cautious bike speed, a run pace that reflects prior brick sessions, or transitions that leave time for finding the correct rack row. Do not slow every leg by the same percentage unless you have a reason to do so. The swim, bike, and run can be affected by different course and personal factors, and the calculator treats them independently.

Put the assumptions beside each result. “Bike speed 29 km/h on the race course” is more useful than “bike average” if the number came from a flat training route with no wind. “Run pace after a 90-minute ride in cool weather” gives more context than a fresh 5 km best. Revisit the scenario if the organiser publishes a course change, if your recent training improves, or if weather is materially different from the conditions behind your inputs. A range of explicit cases helps you plan supplies and pacing decisions; it does not provide odds of finishing or replace the official cutoff schedule.