Why does pace spike or drop to zero the moment you stop walking?
Pace is a small number built by dividing time by distance, and dividing by a distance that has just gone to almost nothing is exactly the kind of arithmetic that produces wild results. The moment you stop, the distance covered between one GPS reading and the next shrinks toward zero, and a figure that behaves normally at a walking speed stops behaving normally at all. It is not a bug so much as the downside of showing a number in real time that was only ever designed to make sense over a longer stretch.
The short answer
A live pace reading is calculated from the most recent handful of GPS points, comparing how far you moved against how long that took. Walking normally, both numbers are well behaved and the pace they produce is stable. Standing still, the distance between consecutive points collapses toward zero while the clock keeps running, so the same division either produces a pace close to zero or, if GPS noise makes it look like you shuffled a couple of metres in that gap, a pace that looks absurdly fast. Neither number is a real measurement of anything â they are both artefacts of dividing by a denominator that stopped being meaningful.
What pace actually needs in order to mean anything
Pace only makes sense as an average over some stretch of movement â minutes per kilometre only describes something real if both the minutes and the kilometre are large enough that a little imprecision in either one barely matters. Over a full hike, small errors in individual GPS points wash out against the total distance and total time, which is why the pace shown for a finished route is a stable, trustworthy figure. A live reading tries to answer the same question over a much shorter window, sometimes just the last few seconds, because that is what makes it feel current. Shrinking the window does not shrink the noise in each GPS point along with it, so the same absolute wobble in position becomes a much bigger share of a much smaller distance.
Why the effect gets worse right at a stop, not just at low speed
A GPS receiver reports a position, not a velocity, and speed is only ever worked out afterwards by comparing two positions and the time between them. Even a phone sitting motionless on a table reports a position that drifts by a small amount from one reading to the next, because that is simply how precise GPS positioning is. While you are walking, that drift is small next to the distance you are actually covering, so it barely shows up in the pace. The instant you stop, your real movement between readings drops to zero and the GPS drift becomes the only thing left in the calculation â a wobble of a metre or two divided by one second of time is enough to print a pace that looks like you are sprinting, or, if the drift happens to cancel out, a pace of zero.
Why the pace for the whole hike does not carry the same glitch
TrailCam reports duration as moving time rather than the raw elapsed clock, and pace for the hike is worked out against that same moving time and the total distance covered â the same pairing that keeps elevation gain and moving time protected from a pause. A short stop to check the map or catch your breath either shows up as a genuine pause, which is excluded from moving time the same way it is excluded from elevation gain, or it is a brief slowdown swallowed by the much larger total. Either way, the handful of seconds where a live reading would have gone strange never gets enough weight in the full-hike figure to move it.
Things that trip people up
- Watching a live pace number closely while stopped and assuming it reflects something real â it is dividing by almost nothing, so it is one of the least meaningful readings a tracking app produces.
- Being alarmed by a pace that briefly looks impossibly fast right after stopping â that is GPS drift over a near-zero distance, not a real burst of speed.
- Expecting the average pace for the whole hike to be dragged around by a few odd seconds like this â it is built from the total distance and moving time, which is a much steadier calculation than any single instant.
- Assuming a pace that drops to zero means the app has stopped tracking â it usually means exactly the opposite: it is still logging your position accurately enough to know you are not moving.
Where TrailCam fits in
TrailCam reports distance, moving time, pace and elevation gain for a route once it is finished, built from the full recorded track rather than from any single instant along the way. A stop to take a photo or check the map does not distort the pace shown afterwards, for the same reason it does not distort elevation gain â both are worked out from the whole route and from moving time, not from the seconds right around a stop. TrailCam is free to download.
Questions
- Is a live pace reading actually wrong when it spikes at a stop?
- It is not measuring anything false, but it is measuring almost nothing meaningful â a real GPS position wobble divided by a real but tiny distance and time. The output number is technically the result of that division; it just is not describing your actual speed.
- Does this affect the pace shown for the finished hike?
- No. That figure is built from total distance and total moving time across the whole route, so a few odd seconds around a single stop have negligible weight in it.
- Why does pace do this but distance does not seem to jump around as much?
- Distance only ever adds up, so a moment of GPS noise contributes a small, one-time amount to a running total. Pace is a division, so the same noise can dominate the result entirely when the distance in the denominator is close to zero.
Recording your own routes
TrailCam is an iPhone app that records your route with GPS, keeps video clips, photos and voice notes pinned to the spot where you took them, and exports the result as GPX 1.1 or CSV. It is free to download.