Is the 10% Rule Real, or Just Convenient?

Ask five runners where the 10% rule came from and you will get five confident answers, none of which include a citation. It appears in Runna’s education tab, in coaching blogs, in the reasoning ChatGPT gives you when you ask it to build a marathon block. Increase your weekly mileage by no more than 10%. Simple, memorable, and almost entirely untested.

It has been tested once at any real scale. In 2008 a Dutch group led by Ida Buist randomised roughly 530 novice runners into a 13-week graded programme built around the 10% rule, or an 8-week standard programme that ignored it. Injury rates came back at about 20.8% in the graded group and 20.3% in the control group. No meaningful difference. Six years later, Rasmus Nielsen’s cohort work on novice runners did find a progression signal, but it showed up at a jump of more than 30% in weekly distance, not at 11%.

So the rule survives not because it works but because it is convenient. It is one number. It requires no data, no baseline, no history, and it fits in a tooltip. That convenience is exactly the problem, because 10% is a ratio and your tibia is not a ratio.

The dimensionless problem

Percentages scale. Tissue does not.

Consider two runners on two AI-built plans. Maya is eight weeks into a Runna 5K plan and running 18.7 km this week across four sessions. Her 10% is 1.9 km, which at 6:45/km is about thirteen extra minutes of jogging, spread as 400-500 m added to each run. At a cadence of 168 that is roughly 2,100 additional footstrikes across the week, a bit over a thousand per leg.

Tom is in week eight of a marathon build at 80 km, generated by Garmin Coach and tweaked by hand. His 10% is 8 km. At 5:20/km that is 43 extra minutes of running, added on top of a week that already contains a 28 km long run and a 12 km threshold session. Same percentage, roughly 7,300 extra footstrikes, and every one of them lands on legs that are already carrying four weeks of accumulated fatigue.

Calling both of those “a 10% increase” is technically true and practically useless. Maya could add 25% and feel nothing. Tom’s 10% is a genuine load event that needs planning around.

There is a second thing the percentage hides, which is compounding. Apply 10% a week from a 30 km base and you get: 30, 33, 36.3, 39.9, 43.9, 48.3, 53.1, 58.4, 64.2, 70.7, 77.8, 85.6. That is twelve weeks to go from 30 km to 86 km. Nobody describes that as a conservative build when you write out the numbers, and yet it is the rule followed exactly.

Calendar weeks are an arbitrary container

The deeper issue is that the 10% rule measures across Monday-to-Sunday boundaries that mean nothing physiologically. Your body responds to load in rolling windows, and a week boundary is just where a spreadsheet wraps.

Here is what that costs you in practice. Tom’s plan looked like this:

Week 3 (Mon 15 - Sun 21):  74 km   long run Sun 21st, 28 km
Week 4 (Mon 22 - Sun 28):  80 km   long run Sat 27th, 30 km  (+8.1%)

Weekly view:     74 -> 80     +8.1%    passes the 10% rule
28-day average:  71 km

Rolling 7-day window, Sun 21 -> Sat 27:
  Sun 21   28.0  (long run)
  Mon 22    0.0
  Tue 23   14.0
  Wed 24   10.0
  Thu 25   16.0
  Fri 26    0.0
  Sat 27   30.0  (long run, moved forward for a Sunday commitment)
  -----------------
  TOTAL   108.0 km    ratio to 28-day average: 1.52

Nothing in Tom’s plan broke the 10% rule. His weekly bars in Strava’s training log look like a textbook progression. But he ran 108 km in seven days against a 28-day average of 71, and he did it with two long runs six days apart. That window is where the injury gets made, and the weekly view is structurally incapable of showing it.

Runna, Garmin Coach and any plan you rearrange around work or weather will do this to you regularly. The moment you drag a session, the calendar-week accounting stops matching reality.

What to use instead

Swap the single number for two checks that you run on rolling windows, not calendar weeks.

Check one: the ratio. Take your trailing 7-day distance and divide it by your trailing 28-day average. Under about 1.3 is routine. Between 1.3 and 1.5 is a deliberate overload week and should be followed by a genuine reduction. Above 1.5 is a spike, regardless of what the weekly bars say. Tom’s 1.52 above is a spike he did not know he was taking. This is the same family of logic behind acute:chronic workload monitoring, which sits inside the wider question of training load and injury risk and is worth understanding properly rather than treating as a magic threshold.

Check two: the absolute ceiling. This is where the 10% rule fails hardest, and where the fix is unglamorous. Once your base is large, cap the ramp in kilometres, not percent:

Notice the top and bottom rows. Below 30 km the percentage rule is needlessly cautious, because 3 km is twenty minutes of easy running. Above 70 km the percentage rule is too generous, because it keeps handing you 8 or 9 km per week at precisely the point where recovery capacity has stopped scaling with volume.

Check three, which almost nobody runs: where the extra mileage lands. Plans grow the long run because that is the easiest place to add volume. Tom’s weekly total went up 10%, but his long run went 28 to 30 to 32 km, and 32 km out of an 88 km week is 36% of his volume in a single session. Keep the long run under roughly 30% of the week during a build. If your plan is pushing past that, the honest fix is more weekly volume, not a longer Sunday.

Reading this in the tools you already have

Garmin Connect computes most of this for you and buries it. Training Status shows Acute Load (a 7-day exponentially weighted total) against Chronic Load (28-day), with a Load Ratio and an “optimal” band, typically around 0.8 to 1.5. The band is wide enough to be nearly useless as a warning, but the raw numbers are good, and the ratio updates daily rather than weekly, which is the whole point.

Coros users get Base Fitness and Load, which behave similarly. Stryd runs a 9-day acute against a 42-day chronic window. TrainingPeaks gives you CTL and ATL, and its ramp rate guidance, around 5-8 TSS per week for a sustained build, is functionally the same absolute-ceiling logic dressed in different units.

If your plan lives in Runna or a ChatGPT document and your runs live in Strava, connect both to intervals.icu. It is free, it pulls your Strava history, and its Fitness chart with load ramp and ACWR will show you rolling windows without you computing anything by hand. Ten minutes of setup replaces every mental-arithmetic version of the 10% rule.

The cutback-week trap

One last thing the percentage rule cannot handle: down weeks. Every decent plan has them. Drop from 80 km to 55 km for a recovery week, then return to 84 km, and you have technically increased by 53%. A strict reading of the rule would trap you at 60 km forever.

Everyone silently measures from the last peak instead, which means the rule is not actually being followed, just invoked. Rolling averages handle this cleanly with no special case: the 28-day window absorbs the cutback, and 84 km against an average that dipped to 72 gives a ratio of 1.17. Fine. Carry on.

Go and open the next four weeks of whatever your app has generated, add up the distance in every rolling seven-day span (not the weeks it drew for you), and find the biggest one. If that number is more than 1.5 times your 28-day average, move a session before the plan moves your calf.