Ground Contact Time and Vertical Oscillation: Useful or Noise?
Your watch has been quietly collecting a second layer of data underneath the pace and heart rate you actually look at. Ground contact time, in milliseconds. Vertical oscillation, in centimetres. Maybe ground contact balance, expressed as a left/right percentage split that looks alarmingly like a diagnosis. Garmin calls these running dynamics, Coros calls some of them the same thing, Stryd wraps its own version into power. If you have a chest strap, an HRM-Pro, a Running Dynamics Pod, or a Coros POD 2, you are collecting them whether you asked to or not.
Here is the claim this post is going to defend: these metrics are mostly a proxy for how fast you were running. They tell you far less about your form than the marketing implies, and comparing your numbers to another runner’s is close to meaningless. They become useful in exactly one situation, which is comparing you to you, at the same pace, over time.
What “normal” actually means here
Search ground contact time running normal and you will land on a chart like this one, which is roughly what Garmin publishes as its running dynamics colour zones for GCT:
Zone Colour GCT (ms)
Purple Top 5% < 208
Blue 6–30% 208–240
Green 31–70% 241–272
Orange 71–95% 273–305
Red Bottom 5% > 305Elite marathoners tend to sit around 180–200 ms. A strong club runner might see 230 ms. A recreational runner in the middle of an easy Sunday long run will often see 280–320 ms and get shown an orange bar for their trouble.
The chart is not wrong. It is just answering a different question than the one you are asking. Those percentiles are built from a population of runners who were, on average, running faster than you are on an easy day. Contact time is inversely related to speed almost by definition: to go faster you apply more force in less time, the foot leaves the ground sooner, and stride rate rises. Sprinters at full tilt are under 100 ms. Walking is roughly 600 ms. You are somewhere in between, and where you sit in between is mostly a function of how hard you are pushing at that moment.
So when your watch tells you your GCT is “below average,” what it is frequently telling you is that you ran slowly today. Which you knew.
A worked example from one actual runner
Take a runner I will call Priya. Marathon PB 4:02, currently eleven weeks into a Runna plan aiming at sub-3:55, running five days a week, Forerunner 265 with an HRM-Pro Plus. Here are her averages pulled from four sessions in the same seven-day block:
Session Avg pace Cadence GCT Vert osc Vert ratio
Easy run, 8 km 6:52/km 166 spm 291 ms 9.4 cm 7.9%
Long run, 26 km 6:38/km 168 spm 285 ms 9.6 cm 7.9%
Threshold, 5×1 km 5:21/km 176 spm 248 ms 8.8 cm 6.6%
Parkrun, 5 km 5:02/km 180 spm 236 ms 8.6 cm 6.2%Look at the spread. Her GCT moves 55 ms across the week, her vertical oscillation moves 1 cm, and none of it is technique changing. It is the same body, same shoes, same legs, four days apart. What changed was speed. The Parkrun row would show up as “blue” in Garmin’s zoning and the easy run as “orange,” and if you took that at face value you would conclude that Priya’s form collapses on easy days and that she should do something about it.
She should not do anything about it. The sensible read is that on easy runs she is, correctly, running easy.
Now look at the fourth column, vertical ratio, which is vertical oscillation divided by stride length. That one is at least normalised for something, so it moves less wildly. Even so it drifts nearly two percentage points across the same week, tracking pace.
The comparison that does work
Strip out speed and the numbers start earning their place. The method is dull and it works: pick one repeatable session and compare it against itself.
Priya’s Runna plan gives her a recurring steady session, 6 km at around 5:45/km. Here is that same session across the block, filtering to the steady portion only in Garmin Connect (or in the Strava lap view, if that is where you live):
Week Steady 6 km pace Avg HR Cadence GCT Vert osc
1 5:47/km 162 bpm 172 spm 264 ms 9.1 cm
4 5:45/km 159 bpm 173 spm 261 ms 9.0 cm
7 5:46/km 156 bpm 175 spm 257 ms 8.9 cm
10 5:44/km 154 bpm 176 spm 254 ms 8.8 cmThat is a trend worth something. Pace held within three seconds per kilometre, heart rate down eight beats, contact time down 10 ms, cadence up four steps. At matched pace and matched terrain, those are all pointing the same direction: she is getting fitter, and her mechanics are tidying up as a consequence rather than as a cause. Nobody told her to shorten her contact time. It shortened because she got stronger and her aerobic system stopped having to work as hard to hold 5:45.
This is the only use of running dynamics I will actively defend. Same session, same route if you can manage it, same shoes ideally, tracked monthly. Everything else is decoration.
And the flip side matters more. If week 10 had come back at 5:44/km, 154 bpm, and GCT of 272 ms, that is a flag. Something changed in how she is moving under the same load. That is when it is worth asking whether she is carrying a niggle, compensating on one side, or running that session on dead legs because the plan stacked it after a hard day.
Ground contact balance and the asymmetry trap
Garmin’s GCT balance shows something like 49.6% / 50.4%. People see anything off 50/50 and panic.
Research on running asymmetry suggests healthy, uninjured runners commonly sit in a 2–3% band off perfect balance, and plenty of people are consistently asymmetric with no consequence whatsoever. A reading of 51.5/48.5 is not an injury. It might just be the way you are built, or the camber of the pavement you run on, or which side you carry your phone.
What does mean something: a sudden shift in your own baseline. If you have run at 50.2/49.8 for six months and a session comes back at 53.1/46.9, and it stays there for a week, that is a change in you, and it is worth paying attention to alongside how your calf actually feels. One run does not count. Sensor placement on the strap shifts, the pod rotates on the waistband, and a single anomalous file is usually the hardware, not the hamstring.
Vertical oscillation and the “bouncing” myth
Vertical oscillation gets framed as wasted energy. Bounce less, waste less, run faster. It is intuitive and it is oversold.
Some vertical movement is how running stores and returns elastic energy in the tendons. Reduce it aggressively and deliberately and you can end up shuffling, which costs you stride length and, often, speed. Researchers have repeatedly failed to find a clean relationship between vertical oscillation alone and running economy. Vertical ratio, because it accounts for how far you travel per stride, correlates a bit better, but even there the effect is modest compared to things like training volume, body mass and shoe choice.
There is one intervention that reliably shifts these numbers, and it is cadence. Nudging stride rate up by roughly 5% typically lowers vertical oscillation and contact time and reduces load at the knee. If you are running at 158 spm on easy runs with a long, reaching stride and a history of knee grief, gently working toward 165 is a real, evidence-backed change. Note what is happening there: the useful lever is cadence, and GCT and vertical oscillation are downstream readouts confirming it worked. They are the dashboard light, not the engine.
What your AI plan does and does not see with this data
This is where it gets practically relevant, because most of you are running a plan that was generated rather than written by a coach who watches you run.
Runna, Garmin Coach and adaptive TrainingPeaks plans do not currently adjust your prescribed workouts based on ground contact time or vertical oscillation. Garmin’s Training Readiness and Coros’s Running Fitness lean on HRV, sleep, acute load and heart rate, not running dynamics. If you built your plan in ChatGPT, it has no access to any of this unless you paste it in. So the fear that a bad GCT number is quietly ruining your plan is unfounded. Nothing is reading it.
The reverse question is the important one. Can you use these metrics to judge whether the plan is progressing you safely? Partially, and only in the matched-pace way described above. Build yourself a simple check: once every three or four weeks, look at your benchmark steady session and ask whether heart rate at that pace is stable or falling. Then, as a secondary signal, whether contact time and cadence are stable or improving. If heart rate is creeping up at the same pace while contact time lengthens and cadence drops, your AI plan is loading you faster than you are absorbing it. That combination, over three or four weeks, is worth a down week regardless of what the app says next.
If you want to know something about your actual technique, a watch is the wrong instrument for the job. Thirty seconds of slow-motion video from the side and from behind will tell you more about overstriding, hip drop, cross-over gait and heel whip than a season of millisecond readings ever will, and the AI gait and form analysis from phone video approach is genuinely a different class of information. Contact time tells you how long you were on the ground. Video tells you where your foot was when you landed, and that is the part that matters.
The practical setup
Turn running dynamics on, leave them on, and then stop looking at them run-to-run. Build one page in Garmin Connect or your spreadsheet of choice with four columns: date, matched-pace session average, heart rate, cadence. Add GCT if you like. Review it monthly, never weekly, and certainly not during the run itself.
Delete the percentile colours from your mental model entirely. A 285 ms contact time at 6:45/km is not a worse number than a 240 ms contact time at 5:00/km; it is the same runner, obeying physics. The person on Strava with the 225 ms average whose form you are envying may simply be twelve kilos lighter and running their easy days too hard.
What you are looking for over a training block is a quiet, boring downward drift at held pace, and the absence of sudden jumps. Priya’s ten weeks gave her exactly that, which is the strongest evidence her plan was working that she could have pulled from her own watch, and it took about four minutes a month to check.