| Metric | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| # | Distance | Split | Cumulative | Copy |
|---|---|---|---|---|
| {{ row.label }} | {{ row.distance }} | {{ row.split }} | {{ row.cumulative }} |
| Scenario | p | Adj % | Finish | Δ vs input | Copy |
|---|---|---|---|---|---|
| {{ row.label }} | {{ row.exponent }} | {{ row.adjust }} |
{{ row.finish }}
{{ row.pace }}
|
{{ row.delta }} |
Race time prediction is the practice of using one measured performance to estimate what the same runner might do over another distance. It matters because a goal that looks reasonable at 5 km can be badly misjudged over 10 km, a half marathon, or a marathon if you do not account for how endurance changes with distance. This predictor applies that idea to a recent race result and turns it into a target-distance estimate with pace and split views.
You choose a previous race distance, enter the official finish time, and select the event you want to predict. The page then calculates a projected finish time, average pace per kilometer and per mile, average speed, and a split table that makes the estimate easier to translate into race-day pacing.
The tool covers standard preset distances from 400 m to 50 km, so it can be used for both shorter performance checks and longer road-race planning. A runner might use it to see whether a recent 10 km supports a half-marathon goal, whether a mile result maps sensibly to 5 km training splits, or how much a slower course should change the expected finish.
Its core model is deliberately simple. The package uses a Riegel-style distance relationship with an adjustable exponent and a condition adjustment percentage, which means it can express how a runner fades with distance and how a hotter, hillier, or faster course might shift the outcome. It does not model fueling errors, pacing collapses, drafting, or abrupt fitness changes between the reference race and the target event.
Read the result as a planning estimate, not as a promise. The closer your prior race is to current fitness and comparable conditions, the more useful the prediction will be.
Start with the most recent honest race effort you have, not a workout split or a badly interrupted event. Leave the exponent at its default 1.06 and keep the condition adjustment at 0% for the first run. That baseline gives you the cleanest view of what the model thinks your prior result implies before you begin tuning it.
After that, use the advanced controls sparingly. The exponent should move only when you have a real reason to believe you preserve speed unusually well or unusually poorly as the distance grows. The condition slider is better for the things the event itself changes: heat, hills, altitude, trail footing, or an unusually quick course.
The package stores every selectable race as a preset distance in meters, including common road events such as 5 km, 10 km, half marathon, marathon, and 50 km. Your previous time is converted from hours, minutes, and seconds into whole seconds, and the target prediction is then calculated from the ratio between the target distance and the previous distance.
The core formula is a distance-power model. The exponent p controls how sharply projected time rises as distance increases, while the condition adjustment applies a final percentage multiplier to account for slower or faster race settings. In practical terms, a larger exponent or a positive condition adjustment makes the projection slower, while a smaller exponent or a negative adjustment makes it faster.
Here t1 is the previous finish time, d1 is the previous race distance, d2 is the target distance, p is the adjustable Riegel exponent, and a is the condition adjustment percentage. The tool rounds the final output to whole seconds, then derives pace per kilometer, pace per mile, kilometers per hour, and miles per hour from that predicted finish time.
The split table is intentionally simpler than the scenario engine. It divides the target event into equal 1 km or 1 mile segments and assumes the same average pace across the whole race, adding a partial final segment when the target distance is not an exact multiple of the chosen split unit. That means the split view is a pacing aid, not a simulation of positive or negative splits.
The scenario table and the charts add the sensitivity layer. Preset scenarios nudge the exponent and condition adjustment around your current baseline, while the Pacing Adjustment Map sweeps condition adjustment from -15% to +30% at the current exponent. The map also shades faster, baseline, and slower bands using a no-adjustment reference window of minus or plus 3% around the baseline prediction, so you can see whether your chosen adjustment stays near the center or pushes well outside it.
| Field or output | How the package uses it |
|---|---|
Previous race distance and Previous race time |
Define the reference performance used for every downstream calculation. |
Target race distance |
Sets the event the model projects. |
Model exponent (p) |
Controls how strongly time grows as distance increases. |
Condition adjustment |
Applies a percentage slowdown or speed-up after the distance model is evaluated. |
Split Table |
Breaks the prediction into equal kilometer or mile checkpoints plus any final partial segment. |
Condition Scenarios |
Compares preset exponent and adjustment shifts against your current inputs. |
Pacing Adjustment Map |
Shows how finish time changes as the condition adjustment moves across its allowed range. |
All of the calculation, charting, JSON generation, and export logic runs in the page. This package does not define a tool-specific server request for race prediction.
Key Metrics tab to compare previous pace, predicted pace, speed, exponent, and condition adjustment in one place.Split Table and choose kilometers or miles depending on how you want to pace the race.Condition Scenarios and Charts & Trends to see whether the estimate is robust or highly sensitive to assumptions.Pacing Adjustment Map only after the baseline projection makes sense. That chart is best for judging how much a slower or faster course could change the final time.If you are comparing possible goal races, keep the prior performance fixed and change one assumption at a time so the differences remain interpretable.
The headline finish time is the fastest way to read the output, but the pace and split views are what make it actionable. A projection of 1:50:19 for a half marathon means more when you also know whether that corresponds to a pace you have trained for and whether the mile or kilometer checkpoints look sustainable.
It also helps to separate model uncertainty from pacing detail. The split table assumes even pacing at the predicted average pace, while the scenario table and decision map show how fragile that prediction may be if the exponent or conditions shift. If those sensitivity views move only slightly, your target is relatively stable. If they widen quickly, the estimate deserves more caution.
Enter a previous result of 5 km in 25:00, keep the exponent at 1.06, leave condition adjustment at 0%, and set the target distance to 10 km.
The package predicts a finish of 52:07, which corresponds to about 5:13 per kilometer and 8:23 per mile. The split table then turns that into roughly even 1 km checkpoints at the same average pace.
This is the cleanest use case for the tool: one recent performance, one longer target, and no extra tuning until you have seen the neutral projection.
Keep the same 5 km in 25:00 reference race, but move to the package's hillier scenario assumptions of a 1.08 exponent and a +6% condition adjustment.
That pushes the 10 km prediction to 56:01, or about 5:36 per kilometer. The change is large enough to matter for pacing and goal selection even though the input race stayed the same.
This is exactly what the scenario table is for: not proving which day is correct, but showing how much the finish time depends on your conditions assumptions.
Use any valid half-marathon prediction and switch the split unit to miles.
The table will list 13 full mile rows and then one final partial row, because the official half-marathon distance is longer than 13 miles but shorter than 14. The package preserves that remainder instead of rounding it away.
That last row is not an error. It is the tool's way of keeping the official race distance and the pacing table consistent with each other.
No. It is a model-based estimate built from a prior race, an exponent, and a course-condition adjustment. Real outcomes can differ when fitness, terrain, weather, or pacing discipline change.
Because the split table uses the predicted average pace across the target distance. It is a pacing aid, not a simulation of progressive fatigue or tactical surges.
No. It only changes whether the pacing table is shown in 1 km or 1 mile segments.
Some official race distances are not exact whole numbers of miles or kilometers, so the tool keeps the remaining partial segment instead of rounding it off.
This bundle does not define a tool-specific prediction API. The calculations, charts, and exports are handled in the page.