| Metric | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| Marker | Distance | Projected clock | Vs base | Note |
|---|---|---|---|---|
| {{ row.label }} | {{ row.distance }} | {{ row.clock }} | {{ row.gap }} | {{ row.note }} |
| Split | Distance | Planned pace | Moving | Stops | Cumulative | Vs base |
|---|---|---|---|---|---|---|
| {{ row.label }} | {{ row.distance }} | {{ row.pace }} | {{ row.moving }} | {{ row.stops }} | {{ row.cumulative }} | {{ row.gap }} |
Race pacing is the simple but unforgiving relationship between distance and average speed. Small changes in pace compound over 5 km, 10 miles, half marathon, marathon, and longer events, which is why a plan that looks modest on one split can move the finish clock by several minutes or more. This calculator turns that relationship into a projected finish time, a split table, and two pacing charts built from the exact assumptions you enter.
The useful part is not just the headline finish number. The package lets you work from either pace or speed, switch between kilometres and miles, anchor the result to a local start time, and then layer in two practical disruptions that ordinary distance-time arithmetic ignores: a course-wide pace trend and scheduled stop time. That makes it more helpful than a bare stopwatch conversion when you are trying to judge whether a race plan still holds after fatigue, aid-station pauses, or a deliberate negative-split approach are added.
A runner might use it while deciding whether a 4:55 per kilometre target is realistic for a half marathon, or whether a 10-mile pace goal still lands before a cut-off once three aid stops are added. Another user might be planning a long supported event in miles, but still want the average speed and cumulative checkpoints in both unit systems for treadmill, watch, or crew-sheet use.
The page is best understood as a pacing worksheet, not a physiological prediction engine. It does not know about hills, heat, wind, fuelling problems, terrain, drafting, or how evenly you personally slow down late in a race. Its effort-trend slider is an explicit heuristic, useful for scenario planning but not a substitute for actual training data or course-specific modelling.
That boundary matters because the tool is strongest when you already have a plausible target effort and want to see what it implies. The split table, segment chart, distance timeline, and exported JSON help you test the plan you are considering. They do not certify that the plan is sustainable under real race-day conditions.
Start with the two variables you trust most: race distance and a target effort. If you think in minutes per kilometre or mile, pace mode is the cleaner entry point. If you think in treadmill or bike-computer style speed, speed mode is simpler. The summary badges immediately show whether the plan is being interpreted in the unit system you intended, which is worth checking before you read anything deeper.
Use the preset list when the distance is a standard event. The package includes 5 km, 10 km, 15 km, half marathon, marathon, 50 km, 1 mile, 10 miles, and 50 miles, and it carries the exact preset distance through the rest of the calculations. Switch back to custom only when the target is a non-standard course or a training route with a precise custom length.
The advanced controls are most useful when you have a reason to depart from flat pacing. A positive effort trend models slowing toward the end, while a negative value models getting faster as the race progresses. Planned stops are spaced evenly across the course rather than attached to real aid-station geography, so they are best used as a rough allowance for bottle grabs, toilet breaks, or short crew stops rather than an exact operational plan.
Read the outputs in order. The summary box and Race Metrics tell you whether the overall finish still makes sense. The Splits tab shows how that total is distributed checkpoint by checkpoint. The Segment Pace chart helps you see whether the trend assumption creates a gentle drift or an unrealistic late-race slowdown. The Distance Timeline is the fastest way to compare cumulative time against course markers or cut-offs.
If the plan is going to be shared, the exports matter. The page can copy or download metrics and splits as CSV, export both tables to DOCX, save either chart as PNG, WebP, JPEG, or CSV, and copy or download the structured JSON payload. That makes it useful for coaching notes, crew sheets, pacing bands, or a training log that needs more than one view of the same plan.
The calculator reduces every entry to metres, seconds, and a constant target speed. Distance is stored internally in metres, with kilometres and miles handled through fixed conversion factors. In pace mode, the tool turns minutes and seconds per kilometre or mile into metres per second. In speed mode, it converts the entered km/h or mph value to the same base speed. Base finish time is then just distance divided by speed.
The effort-trend control is intentionally modest in its math. The slider value is clamped to a wider internal band, then converted into a multiplier of 1 + percent/200 for the overall finish. That is why the interface note says +10% slows the average by about 5%: the setting is not applied as a direct one-to-one slowdown across the entire race. Instead, it becomes a softer scenario adjustment. Negative values do the same in the opposite direction and model a faster overall result.
Split generation uses a more granular version of the same idea. The tool builds 1 km or 1 mile checkpoints, measures each segment against the base speed, then adjusts that segment by the midpoint fraction of the race already covered. Early segments therefore stay closer to the base plan, while later ones absorb more of a positive fatigue trend or more of a negative-split assumption. The last segment is shortened automatically if the distance does not divide evenly into the chosen split unit, and the last row is relabelled as Finish.
Stops are also heuristic rather than course-aware. If you enter a number of planned stops and a stop duration, the script spaces those stop positions evenly by dividing the full distance into stop_count + 1 intervals. A stop is added to the segment in which its scheduled position lands. That makes the total finish and cumulative split clock slower in the right direction, but it does not claim to represent the exact geography of aid stations, queues, or moving restarts.
The JSON tab is not a debug dump. It is a structured export of inputs, adjustments, summary values, and every split row, including distance in both unit systems and cumulative times in seconds and display form. That makes it suitable for feeding a pacing spreadsheet, a coaching workflow, or a training note that needs machine-readable data as well as the human-facing charts.
| Symbol | Meaning in this package | Practical effect |
|---|---|---|
D |
Total race distance converted to metres | Keeps kilometre and mile inputs on one internal scale |
v |
Base target speed in metres per second | Comes from either pace mode or speed mode |
f |
Clamped effort trend percent | Positive values slow the plan; negative values model faster finishes |
m |
Overall fatigue multiplier 1 + f/200 |
Softens the trend into a scenario adjustment instead of a full direct slowdown |
n and s |
Stop count and stop duration | Add scheduled pause time to the projected finish |
r_i |
Midpoint fraction of the race for split i |
Pushes more trend effect into later splits than earlier ones |
p_i |
Number of planned stops landing inside split i |
Places pauses into cumulative checkpoints instead of only the final total |
| Surface | What it shows | Available exports |
|---|---|---|
| Race Metrics | Distance in both units, finish time, finish clock, target effort, average pace, average speed, split unit, and adjustment summary | Copy CSV, download CSV, DOCX, single-row copy |
| Splits | Each checkpoint with distance, segment time, and cumulative time | Copy CSV, download CSV, DOCX, single-row copy |
| Segment Pace | Line chart of segment duration across checkpoints | PNG, WebP, JPEG, CSV |
| Distance Timeline | Cumulative time plotted against distance in km or mi | PNG, WebP, JPEG, CSV |
| JSON | Inputs, adjustments, summary values, and split rows in machine-readable form | Clipboard copy and JSON download |
The finish headline is the fastest summary, but it is not the only result that matters. If the Race Metrics table shows a finish you like but the split table drifts sharply late in the race, the plan may be mathematically consistent and still practically unkind. The charts are there to make that mismatch easier to spot.
A positive effort trend should be read as a late-race slowdown assumption, not a claim about your physiology. The tool applies it evenly through a midpoint-based split adjustment, so it is useful for testing how a fading plan changes checkpoints. It is less useful as evidence that you personally will slow down in exactly that pattern.
Planned stop time can also be misread. The calculator spreads stops evenly because it does not know the real position of aid stations or crew access. If your actual stops are clustered late, early, or on steep sections, the finish total may still be reasonable while the intermediate split locations drift away from reality.
The strongest use of the output is comparative. Try the same distance with flat pacing and with a modest positive trend. Try the same target with and without pauses. If the finish time swings enough to change your race strategy, that is a useful planning signal even though the tool is not pretending to be a full course simulator.
A runner selects the half marathon preset, enters a target pace of 5:00 per kilometre, and adds a +8% effort trend. The finish headline becomes slower than the flat-pace arithmetic, and the later 1 km rows stretch more than the early ones. That is useful when the real planning question is not "what if everything goes perfectly" but "what if I fade a little over the last third."
Another runner works in miles, enters a constant speed in mph, and adds three 20-second stops. The total finish time rises by a minute, but the split table also shows where that time is likely to appear in cumulative checkpoints because the pauses are inserted inside the route rather than only tacked onto the end. That makes the plan more useful for watch alerts or crew expectations.
A marathoner tests the same distance twice, once with 0% trend and once with a modest negative value. The summary line changes only a little, but the Segment Pace chart shows later checkpoints getting quicker instead of slower. That comparison is often more informative than the headline finish number because it tells you whether the pacing shape matches the race strategy you are trying to rehearse.
No. It is a scenario control built into this package. It helps you test pacing plans under a chosen slowdown or negative-split assumption, but it does not measure your personal fatigue profile.
The tool shortens the last segment automatically and relabels the final row as Finish, so the split table still matches the total distance.
No. Stops are distributed evenly across the full race distance. That is good for broad planning and weaker for reproducing a specific course layout.
The package uses the current local time as the start anchor when no local start is entered, then adds the projected finish duration to that clock.