Knowledge Base & Community Forums/Community Forums/Suggest a new Feature

PlannedDoneNot planned

Run Types and Moving Pace - And No Actual Pace

Blaine Browning
suggested this on August 21, 2013, 8:56 PM


What is the difference in tagging a Run Activity as one of these Run Types?

1) Run

2) Race

3) Long Run

4) Workout

5) Treadmill

The one difference I see is that by tagging a Run as a Race, Strava modifies the Pace to be the actual Pace instead of the Moving Pace. On all other tagged Run Types, the Moving Pace is used for mile splits (but labeled as Pace). Also, the Elapsed Time is shown at the top of the overview in large vs small font and presumably calculates the pace from the Elapsed Time.


1) I don't see any KB Articles on Run Types, so please elaborate on them

2) Strava should not be using Moving Pace on Run mile splits - its misleading and not accurate. If Strava wishes to display the Moving Pace vs the actual Pace, then Strava should label it as such.

3) I should not have to switch my run to a Race just to see the actual Pace mile splits.

4) IMO Strava should not even use Moving Pace, its not useful. But if they wish to use it, it should be labeled so people are not confused if it is a Moving Pace or the regular Pace. By tagging a run as Race vs Run we are somehow suppose to know that the Pace has been changed from Moving Pace to Pace? Just label the Pace always and show both. For mile splits, GAP and Moving Pace (labeled as just Pace, misleadingly) are of no interest and the true Pace is not shown (unless the run is tagged as a Race)!


Strava - please straighten out your usage of Moving Pace. We need to see our real pace for mile splits - not a massaged # that looks great even if we stopped at every drinking fountain.

Also, on the Run overview page, the Moving Time shown is not the actual Moving Time, its the Time. Garmin defines the following times; Time, Moving Time and Elapsed Time. Strava is overloading the usage of Time and Moving Time. The label on the web page is Moving Time, but the value is Time. Change the label to Time. And in the mile splits, you do the opposite, label the pace as Pace when its really the Moving Pace. Both of these are misleading, and in the case of mile splits do not even have the actual Pace per mile. iPhone App displays Pace as Moving Pace with no option to see the actual Pace and does not label the Pace as Moving Pace either. This needs to be fixed too.

Quite simply - label the correct values - and show the real mile split Paces. Label Moving Time as Moving Time. Label Moving Pace as Moving Pace. Label Time as Time. Label Pace as Pace. And show the actual mile split Paces (not moving pace) despite how the Run is tagged. labels these values correctly and includes both regular and moving times/paces.





Comments latest first

User photo
Calle Gothnier

If I use a high-end GPS device (which I do) that for some reason struggles with GPS reception (dense tree cover or otherwise tough conditions), I expect my training software to cope with that accordingly. Most apps do that perfectly well, but Strava refuses to acknowledge this and recommends manual intervention to fool the software to calculate correctly (pressing pause during the run for example). I am not willing to pay for something so obviously inferior. And it makes the rest of the Strava goodies uninteresting too since it all will be based on false data. Comparability, anyone?

The most obvious solution would be to let the device handle pauses _if I want it to_ and just show the data as-is, without trying to detect pauses that isn't there.

June 30, 2015, 10:05 AM
User photo
Danilo R.

I use Strava on Android smartphone with Lollipop 5.1 and GPS set to high accuracy.

So far so good. However, as I stated before, the auto-pause on the app was completely wrong. Oftentimes it would consider my logging or recovery pace as a pause. I just disabled. I can see that this issue here is more about dedicated low-cost GPS devices than on Strava. If you use on smartphone with original Strava app, no errors are shown, I have at least 15 friends that used in their smartphones, and no issue.

Honestly people, those who are experiencing problems from where I can see, it's a DEVICE problem. Particularly the low-end ones. So I think it's more of a manufacturer issue than Strava.

If you read all comments, you'll that people using Forerunner 110/210 or whatever are the ones with most problems.

And I say that because the dedicated manufacturer website might be specifically designed to interpret those trackpoints differences automatically. MAYBE, just MAYBE, garmin detects you use FR210 and interpret the missing data with nothing and calculate the time between positions, and, with the high-end devices, it may not even record the data, or it interprets differently.
Either way, you are benefitting someone in prejudice of others.

June 30, 2015, 9:17 AM
User photo
Gregg McKeown

As a follow up to the question I asked at the end of May - I purchased a Garmin 610 and on the few runs I have done with it I am happy to say that the Elapsed Time and moving time are now pretty much the same (Some runs exactly the same, some others 10 seconds or so out) which I am happy with.

Frustrating I had to spend +£100 to get it to work right but I had my other reasons for wanting a dedicated GPS tracker so the fixing of this issue was just an added bonus!

June 30, 2015, 4:28 AM
User photo
Alex Greenbank

> The moving time vs elapsed time is different.

If I upload the raw .fit file from my device Strava thinks I was stopped for more than 5 minutes over a typical 1 hour run (and it can be worse) despite me only stopping for 10 or 15 seconds at most during the run.


If I do my stuff to remove trackpoints with no position information and upload that file (representing the same run) then the moving/elapsed times are exactly as I would have expected (given that I may have to stop to cross a few roads).


No need to set it to 'Race', by cleaning the data I don't give Strava the chance to misinterpret it.

June 30, 2015, 3:56 AM
User photo
Armand D.

Hi Alex, 

The moving time vs elapsed time is different. From the Strava blog - " The moving time calculation on the server looks for portions of the activity where the athlete was moving below a certain speed threshold for more than 15 seconds and removes that time as “resting time”, leaving the remainder as moving time.

That's the crux of the problem, and I suspect it also differs on where your data comes from, so actually no ways to compare two runs on the same stretch not set as race. (I use a Suunto). By just leaving the data as is and respecting the pauses initiated by the runner the times would be as you'd want them. Easy way to see this is just to switch your run to race, viola, Strava doesn't infer their own stops and the run reflects accurately on your profile. 

June 30, 2015, 3:42 AM
User photo
Alex Greenbank

> I'm sorry to say that "bug denial" seems to be an increasing problem among software developers


It's not quite that simple, it's not all Strava's fault. Strava could do something to fix the problem but the problem is mostly due to incomplete data from the GPS and how they choose to interpret/handle this.


I have a Garmin Forerunner 110 and it works very nicely, however sometimes it doesn't put GPS information on the trackpoints it logs, despite there being no reason why it shouldn't have a nice lock on the satellites as I'm running out in the open. Sure, I understand why I don't have GPS points on trackpoints where I run through an underpass or some particularly heavy woods but not all of the cases where I get missing positional data are scenarios like this.

Here's an example from a recent run:-

<Trackpoint><Time>2015-06-18T07:24:16Z</Time><Position><LatitudeDegrees>51.44610657</LatitudeDegrees><LongitudeDegrees>-0.2552643232</LongitudeDegrees></Position><AltitudeMeters>18.4</AltitudeMeters><DistanceMeters>3466.53</DistanceMeters><HeartRateBpm><Value>155</Value></HeartRateBpm><Extensions><TPX xmlns=""><Speed...>
<Trackpoint><Time>2015-06-18T07:24:20Z</Time><AltitudeMeters>18.8</AltitudeMeters><DistanceMeters>3476.64</DistanceMeters><HeartRateBpm><Value>155</Value></HeartRateBpm><Extensions><TPX xmlns=""><Speed...>
<Trackpoint><Time>2015-06-18T07:24:21Z</Time><AltitudeMeters>18.8</AltitudeMeters><DistanceMeters>3483.53</DistanceMeters><HeartRateBpm><Value>155</Value></HeartRateBpm><Extensions><TPX xmlns=""><Speed...>
<Trackpoint><Time>2015-06-18T07:24:27Z</Time><Position><LatitudeDegrees>51.44584942</LatitudeDegrees><LongitudeDegrees>-0.2552864514</LongitudeDegrees></Position><AltitudeMeters>19</AltitudeMeters><DistanceMeters>3495.47</DistanceMeters><HeartRateBpm><Value>157</Value></HeartRateBpm><Extensions><TPX xmlns=""><Speed...>


4 trackpoints, first and last have position data, middle two do not. There is some tree cover there in Richmond Park but hardly what I'd expect to be enough to disrupt the satellite reception. Even so, the "DistanceMeters" counter is increasing during this time (and the 'speed' value doesn't seem to be guesswork based on other examples). But the point is that I didn't stop running there, and analysis of the points before/after will show that I must have been moving during that time where it had no signal.

Strava chooses to interpret trackpoints with no GPS information as stationary periods, even though the points immediately before and after the ones without GPS positional data are a reasonable (spatial) distance apart and consistent with continuous movement at whatever pace I've been running at.


In the above example it assumes that I had stopped between 7:24:16 and 7:24:27, because there trackpoints between those times had no position information on them. So that's 11 seconds of time stopped right there. This file has a further 27 trackpoints with no position information, and so it slowly builds up more and more time where it thinks I was stopped. This depsite the distance between those points 11 seconds apart is ~29 meters, consistent with me plodding along during that time.


On a more general level (and thinking about the algorithms they'll need to implement to fix this) it gets tricky. Take a gap of 10 seconds or so (happens quite frequently like the above):-


The simple case (like the above) is that there's a period of 10 seconds where I move a further 30m down the road (consistent with running at ~11kph for 10 seconds). In this case it's quite easy for Strava to assume that I hadn't stopped at this point.

But what there's a period of 10 seconds where I move 10m down the road. Did I run for 3 seconds and have to stop to wait to cross a road? Did I walk for those 10 seconds? Did I try and run for those 10 seconds but it's an evil steep hill and I was going at a third of the usual pace? With missing data Strava can't tell, and this is probably why it's not so easy to tackle this problem.


There are a few points on my runs that I do have to stop but most of the time I don't get missing position data on the trackpoints at these points. With position information Strava's algorithms can correctly detect that I've stopped and the moving/elapsed times will be accurate.


What I do to get around all of this is convert the .fit file to .tcx (using Fit2Tcx) then use some perl scripts to reformat the resulting xml and strip out the points that don't have positional information on them. I then upload the resulting file to Strava. Strava then uses it's algorithms to pick out the points where I've stopped (based on consecutive trackpoints being very close to each other) and I get accurate moving/elapsed times (and therefore pace).


Strava could address this issue in a couple of ways:-

* Ignore trackpoints that don't have positional information (which is what my filtering scripts do, to good effect).

* Or, don't ignore the points without positional information but analyse the points before/after them and decide whether the bounding points mean that movement was continued during this time and effectively interpolate


It also explains why some other devices don't suffer from this problem, as they may not log a trackpoint without position information, or they log frequently enough that one or it only affects one or two trackpoints and so stopped time is negligible.


It's just a pain, for me, to have to clean up each of the files before I upload them, it would be much nicer if Strava was aware of this issue and wanted to address it.


Of course, the problems seen by people in this bug report may be caused by some different issues, but removing trackpoints with no positional information completely solved the problem for me and, at the underlying technical level, I can guess that this is due to certain assumptions in Strava's algorithms.

June 30, 2015, 3:30 AM
User photo
Armand D.

It really is a disgrace and insult to Strava users running trails (or road for that matter) that you don't get to decide when you are actually running. Perhaps if it's such a big thing for them to change the default behavior why not add another run-type - "trail", or "real run" or something. And choosing that as a default will leave the decision about pausing your watch up to you, as it should be. 

Sure moving time looks good - I'm running a 100-miler in August and I know according to Strava I'll be beating Kilian Jornet. Can't wait. Run less, perform better. The Strava way. 

June 30, 2015, 2:17 AM
User photo
Calle Gothnier

Or, do as I did - stop paying for something that doesn't work. They lost me 2014, seems like they won't get me back 2015 either.

June 30, 2015, 2:03 AM
User photo
Scawen Roberts

I'm sorry to say that "bug denial" seems to be an increasing problem among software developers. Basically, regardless of what we say, they have decided that this is working as intended. They won't take that minute or two to understand what we are telling them, because they prefer to think everything is OK and that we are basically a bunch of nutters. It's easier to believe that because then they don't have to spend a few minutes fixing the bug. Probably they have unsubscribed from this thread and it's something they have already dealt with, never to be looked at again. So for now I think our only option is to use the workaround. Just stop your watch at some point during the run and start it again.  Just when you go through a gate, over a stile or something. Strava does detect this when you upload and disables the faulty algorithm that detects stationary periods.

June 30, 2015, 1:47 AM
User photo
Cheryl Jenks

I'm kinda tired of see 'moving time' for runs completely underestimated.  Anyone at Strava ever been for a gnarly trail run????  Clearly not......

Oh for them to fix it


June 27, 2015, 4:36 AM
User photo
Danilo R.

I'm a new member but as far as I can tell, the numbers are good. I just use my phone Android to track.

However, if I set up the "auto-pause", it will pause randomly in very strange moments. This feature is not ok to use. When I do runs/jog/runs workouts, everytime I'm jogging, the app thinks I'm not moving, thus, auto-pause. Everytime I get my phone out of my pocket, this happens too.

The solution so far was to disable the auto-pause. Now it works good...

June 14, 2015, 1:51 PM
User photo
Nick B.

@Gregg McKeown - The issue mostly disappeared for me when I moved from using my phone to track runs, to using a Garmin 910XT.  I can't comment on the 610, but I imagine being a dedicated GPS device it'll have a similar result.  Would be keen to see if others have had similar experiences when switching from phone to Garmin / other GPS sports watch though...

May 29, 2015, 9:46 AM
User photo
Gregg McKeown

Quick question - I am considering purchasing a Garmin Forerunner 610 watch.  Will I still see this problem on my run activities uploaded to Strava?  Currently using an iphone to track just.



May 28, 2015, 2:35 AM
User photo
Steve Marr

One last little comment from me before I unsubscribe from this thread, hopefully this might be helpful for some...

For the last 6 months I have been getting around the moving pace thing by doing a quick "stop-start", "stop-start", at some point in each run, which then forces Strava to show the elapsed time rather than moving time. Which has actually worked fine apart from the odd time when I forgot.

So I guess that could also work for some of you as a fix (albeit a slightly annoying one).

However, I now have a permanent fix for this issue and that was to buy a new watch... I have just upgraded from the Garmin Forerunner 110 to the Garmin Forerunner 220, and it has completely fixed the problem... Now my elapsed time is virtually identical to my moving time, every time I go out for a run :-)

So I guess that this higher spec watch catches and records data in a different way to my old one; and whatever it is doing, is clearly more agreeable for Strava.

Happy running people!

May 1, 2015, 7:28 AM
User photo
Gregg McKeown

Just another user adding my concern for this moving time used by Strava - I have always used Runkeeper and recently imported all my activities across.  Went for a run last night, tracked it with Runkeeper and synced it over to Strava and it removed 3:25 from my run (which was only 38:21).  Interestingly a ran with someone who used the exact same process (Runkeeper to track and sync over) and it matched out runs but with hers it is only 46s difference (again we only stopped once at a set of lights for 20s max but at least it is a bit more accurate!)

Strava need to either remove this or give the user an option of changing it themselves...

April 30, 2015, 3:22 AM
User photo
Wojtek Lisak


First, a little introduction. I'm free, not a premium user, I use different watches (Garmin 910XT, Garmin Fenix 2, Suunto Ambit 2). Recently I've been using 910xt. Activities are transferred to Strava automatically from Garmin Connect.

I'm totally confused by the way that Strava shows data on the activity page.

First of all I think Strava should be showing pace basing on activity time and not moving time counted by Strava (in the case of my recent activities with the Garmin 910xt the moving time is taken from Garmin's activity time so it's ok because Strava does not count it by itself).

But what struck me yesterday was the table that shows laps.

I have a recent activity marked as "run". It was a run consisting of three "laps" 3,2km + 21,1km + 3,6k. I had to stop quite a few times during the run (especially in the 2nd lap), so every time I stopped at the traffic lights I stopped my Garmin and I started it again when I started running again. The thing is that Strava takes ELAPSED TIME for this table! I do not understand why. If I wanted to know the elapsed time I wouldn't bother to stop the watch at every traffic lights. I did that so I can know the exact pace I did on that lap.

I read most of the thread but I haven't seen anybody complaining about this. For me lap times and lap pace is way more important than the splits.

I think the way the data is displayed on Strava is very misleading.

And the solution is very simple. Strava should show all the times and the pace for all these times: "real" activity time, elapsed time and (if it's so important for so many users) the moving time calculated by Strava. And all of these three different times/paces should be showed everywhere: in the overview, in the splits table and what's important to me: THE LAPS TABLE!

I started using Strava because I've got both Garmin and Suunto watches and wanted to have all the activities in one place, but I am very disappointed by Strava and now I rather analyse my activities in Garmin Connect.


Best regards,


March 25, 2015, 8:00 AM
User photo
Espen H.

Strava shaved off 2min 11sec on my last run. I also used Runkeeper to compare (with auto pause). I didn't stop once, so where/why did they cut 2.11 of my time????????? This is not good enough Strava!!!!

February 23, 2015, 3:29 AM
User photo
Scawen Roberts

Why is this thread in "Suggest a new feature" section?  It should obviously be in the "Report a Strava Issue or Bug" section.

Strava developers could:

1) Fix this issue in 10 minutes by adding an option to avoid removing stationary time, as they do for races.

2) Also fix the bug (e.g. on Forerunner 110 watches).  The reason for it has been described here by Alex Greenbank.

It would be great if they would do it, as it is quite frustrating to have to remember to randomly stop and start the watch at some point during the run.

February 15, 2015, 10:29 AM
User photo
jzy two

Hoping I can find a way to use my authentic time in activity. Perhaps there is a "real" term for it, perhaps say: clock time? Say I start an activity and an hour and a half later I stop it. Well, it would be nice to trust the 1-1/2 hour elapsed time. Strava doesn't allow me to do this, and why I just don't know, but I wish I could override this setting.
Yes, I realize there is a run and ride auto-pause function, but I don't see the value of it, if the server is going to delete non-moving time anyway.
If I have to stop to tie my shoe, vomit, drink, pick up litter, etc I feel it would be nice to pay for the luxury by having my time docked for the rest. This is not the way Strava seems to record my runs.
I've been using Strave, MotionX-GPS and Wahoo Fitness apps on my iPhone 5s for the last year and a half. Strava ALWAYS shows shorter times on the trail and thus a faster pace. I don't feel this is accurate. My race times do not take into account how many times I stop to rest, talk or take pictures or wait in line at the sani-can. I feel because Strava subtracts these idle minutes (that I don't have control of adding back in) that my times according to Strava are fictional, not real world, rather "feel-good" numbers that do not compare properly with race day times.
Granted, I accept that I may have my settings set incorrectly. I seem to find only one place to adjust them: Setttings>Ride auto-pause button or the Run auto-pause button. Both of mine are turned off (showing only a white circle, not with the orange background and white circle).
Might there be another place for me to set this to show my correct clock time in the event?

February 14, 2015, 12:43 PM
User photo
Scawen Roberts

Interesting what Alex Greenbank said about the data points from the Forerunner 110 watch missing position data. Strava informed me during an email exchange that, inexplicably, the data from my watch (also a 110) had several points where the position data was identical to the previous point, and this is why Strava assumed I was stationary for a couple of minutes during my non-stop runs. This was coming up for two years ago, when the new run pages were introduced. They said they were working hard on this bug. Still here now... and Alex may have the explanation there. Suppose the data from the watch doesn't has missing position data, just as he found. Then Strava's initial interpretation of the data has a little code that leaves any data point that is missing position data, with the position data from the previous point. And that may be the explanation for the inexplicable duplicates of position.

So now we have a possible explanation for the false resting time detection, please could that be fixed?

And also, please could we have an option to not detect resting time - like a race run?  So easy to do.

February 5, 2015, 11:53 AM
User photo
Nick D

Add me to the list of folks who would like to default to elapsed time instead of moving time. I have to believe that any runner who says they want the moving time must simply not understand this issue. As many others have experienced, I run without stopping, yet Strava insists that I wasn't moving for large chunks of time. My pace is artificially low EVERY TIME I RUN, even though I never stopped. No one who realizes this could possibly prefer to use the "moving time."

February 5, 2015, 10:11 AM
User photo
Tom B.

To further demonstrate the unreliability and inaccuracy of Stravas data processing on runs take a look at this recent fiasco. (A.k.a let's beat this dead horse a bit more)

Garmin Connect activity recorded with Forerunner 220
Strava activity automatically synced (I manually paused the watch at the top for a few minutes to soak in the lovely view and the times match!)

Now get this: a few days later I get the same activity automatically synced as a grouped run with MYSELF? If I delete the second one it just keeps coming back so I've flagged it.

The "moving time" and pace of the Strava activities are different. About 5 minutes off. 

Quite a few discrepancies here.
1. Supposed group activity but different moving times.
2. Same data source but different results
3. Supposed group activity but being assigned to the same person - me
4. Manual pause on the first auto import honoured but not on the second 

So as we can see Strava alters the data and then can't even recognize it as the same activity. 
No bueno :(

I wrote Premium Support. Can't wait for the response :P

January 22, 2015, 1:51 AM
User photo
Alex Greenbank

Similar problems for me (Moving time is considerably less than Elapsed time despite not stopping on the run). Forerunner 110.

I converted my .fit file to a tcx to take a look at the actual data.

I see various points that have no position information in them (see middle trackpoint of attached image). Note that this missing position data is in the middle of a run (5km in) and not near any buildings that should interfere with GPS reception, so no idea why the watch is not recording a GPS position there.


More importantly, if I remove the points with no Position tag and upload the resulting tcx file the moving time is correct (i.e. it matches the elapsed time) and all of the remaining bits (pace/etc) are correct. 

I'll try adding positional information to the points (by interpolation of the previous/next points) so that I don't lose the HR information contained within these points.


Annoying that I now have to pre-process my runs before I upload them to Strava to workaround their algorithms.

January 21, 2015, 1:38 PM
User photo
Steve Marr
One more thing... Fix your Apple apps (please), you can mark a run as race and it makes bugger all difference anyway... Just tells the same old lies as if it were marked as run... Don't know why I'm bothering to write this though as clearly no one is listening.
December 18, 2014, 4:16 PM
User photo
Steve Marr manipulate your data when clearly people just want it as it comes? And why oh why oh why do you just keep on ignoring your customers???
December 18, 2014, 4:13 PM
User photo
Steve Marr
Strava... Is there anybody there..? Why have you chosen to ignore your users/customers for so long? It blows my mind that you choose
December 18, 2014, 4:07 PM
User photo
Tom B.

I wonder how many runners actually stop during a run? I know I don't. If a runner does need to stop for any reason they can always pause their device or the app manually.
As long as the watch or app is tracking it should be assumed that the athlete is moving. This would eliminate any need to guess when the runner has stopped or is tying their shoelaces.

If a dedicated gps device like a forerunner is being used for tracking, Strava should let the device deal with auto-pausing and not try and cut out seconds where it thinks they were not moving.
If Strava wants to play around with how their own app handles moving thresholds and auto detecting pauses, thats ok with me  but as long as a dedicated gps device is being used then they should respect the data and not mess with the results. 

December 18, 2014, 7:07 AM
User photo
Scawen Roberts

I confirm that the "manual pause for a couple of seconds" workaround works with my Forerunner 110.  At some point during your run (maybe at a stile or a gate if you encounter any) just stop the timer then start again maybe 3 seconds later.  Usually I forget that, I'm too busy vaulting the stile or whatever, so then at the end, I restart the timer a couple of seconds after I've finished, then stop it again a couple of seconds later.  This is annoying but has a minimal effect on the run stats.  It's better than having to contact Strava support after every run because they usually credited me with around 90 seconds of resting time on every 20 minute run.

December 18, 2014, 6:22 AM
User photo
Adam Engst

I've left a comment on the blog post about Auto Pause, encouraging the developers to read this thread because of the connection with data accuracy. Perhaps that will raise the profile of this issue as well as help other Strava users understand what's going algorithmically. Others might wish to post their concerns about data accuracy as well.

December 18, 2014, 6:18 AM
User photo
Adam Wenborn

Hi Mike,

I believe you would have to include a manual pause on the Garmin during the activity as well. To quote Elle's reply from below:

"If you have a Garmin run device, turn off auto-pause, and use the manual "Stop/Resume" button at least once during your run, the Strava will NOT overwrite your time data with it's algorithm for detecting resting time. Instead, Strava will display the time data according to the "timer time" of using the Stop/Resume action. In theory, you could use this button for a brief instant at the beginning or end of your run and then you would see pace times that reflect your total time."

I can't be bothered with that so I don't know if it works; I just use Garmin Connect for any analysis.

December 18, 2014, 6:07 AM
User photo
Fcrc Mike G.

Adam, one thing I have noticed is a comment on the Strava support website that states:

If you choose to pause your run activity manually on your Garmin watch, we will honor that choice and represent your Moving Time according to the time and pace shown on your GPS device.

I've understood this to mean that, if I turn off auto pause on my Garmin, then Strava will also honour this setting and I won't ever have to worry about seeing Moving Time again - Strava will essentially always show actual time instead. Can anyone confirm if this is right? I've only just bought a Garmin (collecting it from my local Amazon Locker later today) so I'm wondering if anyone has any experience of this already.

December 18, 2014, 5:47 AM
User photo
Adam Wenborn

Well since this thread is up and running again, it's probably worth mentioning that the Strava Engineering blog posted an interesting piece on Auto-Pause a couple of days ago. It primarily addresses the functionality of the Strava iPhone/Android apps, but there's some interesting points in there regarding this topic of Moving Pace vs Actual Pace.

Firstly, they reaffirm their belief that people primarily want to see moving time/pace; fine, I don't agree with it but if it was implemented in a half-decent fashion I guess I could get along with it.

Secondly, they essentially acknowledge that using GPS location data for auto-pause (and thus define moving time) is completely inadequate:

"...we first tried building run auto-pause based on GPS location updates similar to the way we had built ride auto-pause. Unfortunately, it was not responsive enough — resuming was fairly quick and usually happened within a couple of seconds of the athlete starting to run, but pausing sometimes took 5 seconds or more of standing still. [...] We experimented with making it more sensitive to minor GPS movement, but that caused errors — it would sometime pause while running or resume while standing still.

This is essentially the same issue that we are all experiencing here with post-hoc uploads to the site.

I did have a quiet laugh at the final line though, I wonder if they've read this thread:

"At the same time, it has given us a lot of ideas about other ways we can serve our athletes better in the future, particularly in the realm of data accuracy."

December 18, 2014, 5:40 AM
User photo
Alex Hall

I recently did a workout on the indoor track. I switched my Garmin to "Indoor Mode" and just used the stopwatch function for a 5 mile run which took me just under 28 minutes. Through Garmin Connect, Strava pulled this activity out and gave me a moving time of 22 minutes for a "treadmill" run. This was a continuous run workout with absolutely no stoppage time. Where did Strava decide that I just randomly wasn't running for 5 minutes of the workout?

I've let my Premium membership lapse this year. As a customer with concerns that have not been properly addressed, I'm forced to talk with my wallet. I love Strava, but this one feature really makes NO sense. I've been a runner for 14 years, and at no point during my career would I want your calculation to address my performance and fitness.

December 18, 2014, 5:04 AM
User photo
Murray R.

Is the simple solution not to make the default activity type "Race" and maybe rename it "Training Run"  and have another tag as "Moving time" for any people that want to cheat themselves and just look at their moving time?  This can't be a hard request can it?

Alternatively, have an options in our settings where we can select our default activity type.  Labelling interval training sessions as races is just daft! 

December 17, 2014, 4:04 AM
User photo
Fcrc Mike G.

Hi Elle,

I've just spent a few hours importing my data from Nike+ and was extremely excited about using Strava, especially taking into the account the premium features which I intended on paying for. That was, until I discovered the issue of Moving Pace, which told me my fastest ever mile was 3:55. Boy, I wish it was. I've now read this forum post and realised that the the only 'workaround'  that can be suggested is to mark all runs as Races. Wow. That's terrible.

Can you please let your developers know that I now WON'T be using Strava. You've lost a potential paying customer.

I don't believe that Strava has have any evidence that 'this is what most of our customers want', but this is ACTUALLY what the developers want. The suggested workaround would mean I can no longer use one of the built-in features of Strava (distinguishing between run types), so this is quite insulting and actually devalues the website's feature set. I echo all of the sentiment on this forum. The default should ALWAYS be the actual pace and elapsed time. Moving pace should merely be an OPTION.

The thing that confuses me the most though, is that you've built such a detailed, granular platform on which runners can analyse their progress, and then you ruin it by masking the raw data with a system that hides true performance. Can your developers REALLY not see why this makes no sense? Why do they refuse to look beyond their own, bias point-of-view?

Why should a training run - i.e. which blatantly isn't a race - be any less important than an actual race, when I'm trying to analyse my splits? If I'm not fit enough to run 5 miles without taking a 2 minute break, then the stats NEED to show me this! Under what circumstance would ANYONE that takes their training seriously not want to see this by default?

Your developers should realise that their stubbornness is now having an effect on Strava's revenues, since I have no intention of paying for a service that thinks it's right to distort my runs so drastically. The other users on this forum have all been polite and courteous, but your developers really are treating them with absolutely no respect in return. Have they personally read this thread and seen the volume of support this requested change has?

It's such a shame that your impressive website and infrastructure has been completely ruined by something so critical - but that would have been so simple to solve.

December 16, 2014, 4:34 AM
User photo
Nick B.

Giving this one another bump.  Went on a canal run in London today, and apparently averaged 5:09.....per mile...  1h03m elapsed time, which Strava generously corrected down to 42m courtesy of a lot of bridge along the route which cause short breaks in the GPS.  Stupid, pointless feature to force on users without any ability to manually switch it on / off.  That'll be one more user here on the list of those who were considering premium but now WONT be courtesy of this, and will be advising others in my run and tri clubs to do likewise until fixed.  

Endomondo is an excellent, accurate alternative for those looking.

December 7, 2014, 5:47 AM
User photo
Armand D.

Beating a dead horse but here's an interesting one: Strava decided that Kilian Jornet was moving too slow on the Rut 50 and gave him a bonus 6 minutes where they considered he wasn't moving.

I've yet to meet a runner that considers this calculated moving time desirable. 

November 20, 2014, 6:24 AM
User photo
Elliot Hind

Thanks guys!  I've since asked friends how they see my runs on Strava and the conclusion very much is (if I've set it as a race):

-Web Browsers > Elapsed Time

-Android Apps > Elapsed Time

-Apple Apps > Moving Time


Strava updating their Apple App to show the Elapsed Time when you've selected race would go a long way to helping the issues that a lot of us our facing.

It still makes absolutely no sense at all to me to have Moving Time (and pace) for runners. 


November 18, 2014, 8:11 AM
User photo
Adam Engst

Nice half, Elliot! Just to support your statement about not upgrading to the premium version, I'm in exactly the same boat. I was about to upgrade, and was evangelizing Strava in the local running community, but learning about Strava's attitude toward running time and pace just soured me on it for serious runners. It's a shame, since the impression Strava gives is that it's a service for competitive folks, but the data has to be reported accurately. Or, as I've suggested before, we should be able to edit the times and distances to be accurate without having to delete an event and enter it manually, which achieves the same thing with a lot more work.

November 18, 2014, 6:53 AM
User photo
Steve Marr

Oooh nice running Elliot, cracking time over HM!


While I’m bored of arguing that Strava should do away with this moving pace thing for running, I have come to the conclusion that they are not going to budge, and until I upgrade my Forerunner 110 to something more expensive that works with Strava better I am just stuck with it...


But I just wanted to back you up on the app thing...

If I mark a run as “race” it will show as:

Elapsed time on the computer

Elapsed time on an Android phone

Moving time on an IPhone

Moving time on an IPad


Essentially meaning that whatever you tag the run as you still end up showing a time and pace on the Apple apps that show you better than you actually are... which unfortunately just makes using Strava considerably less enjoyable than it should be :-(

November 18, 2014, 1:19 AM
User photo
Elliot Hind

I am also using a Forerunner 110 and get so frustrated with this issue!  Things have got a lot better recently as the 'Race' feature does bring through my correct splits on the full site, but it doesn't on the iPhone app.  The great thing about Strava is the community aspect and sharing runs with my friends.  I have improved massively, but they all think I'm much quicker than I am!! 

Here is my example from yesterday at the Gosport Half Marathon (an excellent event I recommend):-

Gun Time: 1:15:58

Chip Time: 1:15:56

Elapsed Time on Strava (and the time shown on Garmin Connect): 1:15:56 (so far so good) - pace 3.35km (exactly what I actually did!!!)

Moving Time: 1:11:50 - pace 3.24km


I just don't understand why any runner would possibly want 'Moving Time'; it is completely meaningless.  How can it think that I stopped moving for 4 minutes during a half marathon!? 

I logged it as a race in Google Crome (which it continues to show the 'Elapsed Time' and the correct splits, but on iPhone it is showing that I ran certain KMs in less than 3 minutes!! 


Please please sort this out Strava, I currently use the free version, but genuinely would pay the Premium (as I love the idea of the heat map to see how much of my home city I have covered), but there is no way I will until this issue is sorted.




November 17, 2014, 3:07 AM
User photo
Scawen Roberts

Sorry, I use a Forerunner 110.  It shows up in Strava as a Forerunner 210 but is actually a 110.

Dear Strava, please admit that false detection of resting time is a bug... and fix it.

October 24, 2014, 9:31 AM
User photo
Scawen Roberts

That is terrible to hear they don't consider this a bug.  I always run at a pace of between 4 and 5 minutes per km.  I never stop on my runs and they are mostly between 4 and 6 km.  But nearly always, Strava gives me up to around 2 minutes of resting time.  I repeat - I DO NOT stop on my runs.  This IS a bug.  This has happened ever since the 'new' run pages were introduced.  It didn't happen on the old pages (which were much better in all ways, for anyone who wasn't here back then).  I write to technical support after nearly every run, because they can click a button to reprocess the run without the false resting time.  Maybe we could have a "fix the bug" or "I didn't stop" button...?  So we don't have to contact technical support after most runs?  Like others here, I don't want to mark these runs as a race.  Technical support have told me they are working on this.  But it's much longer than a year and they are still telling me they are working hard on this.  Well over a year, to fix one bug... seriously...?  I am a programmer and it's obvious there's something wrong here.  Anyway, assuming they are telling the truth and are just total beginner programmers without the first clue, how about something simple - a new run type "non-stop run" or "continuous run" that is processed like a race (just ignore the falsely detected resting times) but doesn't appear as a race?  I am using a Forerunner 210.  I understand there are repeated data points.  You just have to filter them out.  I don't keep frequently stopping for 10 seconds then sprint down the road as fast as a greyhound.

October 23, 2014, 11:55 AM
User photo
Adam Wenborn


Nah, only joking, they haven't. But they have added a little 'info' icon next to a lot of the fields on the Activity Page so that you can try to work out for yourself what data it's showing you. I guess that's probably as close as you're going to get to a resolution on this issue. 

As others have said, it's not so much the woeful implementation of "Moving Pace" that is the issue, it's the fact that Strava is manipulating your data without making it clear that this is happening. This latest addition attempts to address that, if only in the most minimal fashion possible.

The obtuseness of the Strava employees detailed here is quite astonishing really. If they want to keep using Moving Pace by default that's absolutely fine, but mislabelling those fields e.g. in the 'Splits' tables is misleading, take Amber's case below as a prime example why. It's not surprising to see that the related issue regarding "Weekly Time Totals" that I raised on July 29th 2014 has not been addressed either.

I'm done with using Strava for anything to do with running. The moving pace calculations are garbage and I'm not tagging everything as a race.

October 21, 2014, 8:00 AM
User photo
Amber Nicole

I also would like this fixed. I spent a lot of time trying to figure out why my times were faster than my running partners and why the final times were different than what I was pacing during the run. Good to know to label it as a race, but that kind of makes me crazy, since I'd like to keep my actual races separate. 

This original post was made in Aug 2013 and now it is October 2014 and people are still having issues. I think it's fair to say that the users want to know the accurate time of their runs.  To be honest, I'm considering shopping around for another more accurate app. 

October 16, 2014, 8:44 PM
User photo
Christian Mace

@Blaine. I agree, it would just be adding 7 characters. I was suprise to hear the answer that this would be complicate, but I don't do web site so I don't know... And yes EJ is mixing arguments between multiple aspects... His point was that runners will not understand what is moving pace... I think it is a bit  condescending to say that. I think EJ was understanding the problem, but he was finding arguments to keep the problem as it is. I hope other people will open ticket on that subject for making Strava realize that they are doing the wrong thing.

October 14, 2014, 5:03 AM
User photo
Tom B.

I think you should not use it that way. You paused the watch and kept walking several times. You should not keep moving while paused because then you have big gaps in the GPS recording. You stop at a GPS point and then suddenly start at a new location so this throws the whole tracking off.

The pause trick is only for a short time to make strava not use automatic pausing algorithm. If you walk / run then either set the watch for that (some devices have that walk/run setting) or keep the watch ON as you normally would while walking. The pause trick is only to be used once either at the start or end of the run, for example, and just for a few seconds. For best results stand still while pause for a few seconds. Hope that helps

October 14, 2014, 12:34 AM
User photo
Stanislav C.

The method mentioned in this thread of using a pause on the watch to trick Strava into correct pace calculation just plain doesn't work for Suunto devices.

I used a pause several times on a recent slow run/walk with my daughter. Strava counted all segments that we walked with paused watch as if we moved through them very quickly with a pace like 1-2 min/mile. I ended up having quite a bit more mileage on Strava than on my watch (3 miles vs. 2.3) and a significantly faster average pace than the actual one. This was a fun run so I don't care too much about inaccurate result, but still it shows how wrong Strava interpretation of the data can be. 

Here is the activity: 

October 13, 2014, 11:49 PM
User photo
Blaine Browning

@Christian EJ still does not understand your request if you read through it - even discussing Moving Time and Elapsed Time, not Moving Pace and Pace and the associated labels. EJ says, "Redesigning the activity page is a serious endeavor for any site." We are talking about changing text from "Pace" to "Moving Pace" to accurately represent that piece of data. Its a simple bug fix - as a Software Engineer myself. And EJ says, "it might confuse users much more to add additional terms" - preposterous. To name something what it is is clarity, not confusion. If a pair of shoes are red, you label them as "red" not "blue" and that is not confusing. It is beside the point if EJ lives in an urban area and is a "fan of moving time calculations". What we are discussing here is labeling moving pace as "Moving Pace". Precisely prepending 7 characters to a label. Strava runners need to understand with this correct labeling that the pace showed to them is actually their Moving Pace. And it is not only runners that it confuses but whomever you share that running activity with. How would they know that they pace you shared with them on social media or via link etc that that data is not your true pace? Moving Pace needs to be labeled as "Moving Pace", period.

October 10, 2014, 1:47 PM
User photo
Christian Mace


If you want the rest of the discussion, I insisted on the first step that need to be done : Change the label of "paste" to "moving paste". Discussion is to be read from the bottom to the top (and sorry for my poor English!):

EJ Noreika, Oct 10 11:52 AM:

This is just the design team decision. With moving time right next to pace, I would assume that's how Strava is calculating pace.

Strava Support Team

Christian Mace, Oct 10 11:47 AM:

Okay, even if it is not logical, I think, you helped me understand the logic underlying your decision... But I think you can have more confidence about your public (runners) and their capabilities for understanding the term "moving pace". It is easy to define it in a couple words as it is easy to define "pace" in a couple words. I also think you are the only one (from main running apps / web apps) who are confusing those two terms. According of what you said, runners are not able to understand the terms in all other apps.




EJ Noreika, Oct 10 11:28 AM:

Because there's so much going on with activity pages already and how most users are acquainted with the layout, it might confuse users much more to add additional terms. Redesigning the activity page is a serious endeavor for any site.

Most users think of pace as judged against time when they're moving, and if they do stop for whatever reason, they're not thinking of that as part of their pace. At least when activities are listed as a race, only elapsed time is used, since you should be moving the entire time.

Strava Support Team

Christian Mace, Oct 10 11:21 AM:

Thanks for the discussion around Strava. You seem to agree it is a bug... but your team doesn't, as I understand the situation. Thanks anyway... Just changing "pace" to "moving pace" and let it pas in the "race", would be a very nice thing to do and it would not be so complicate no??


EJ Noreika, Oct 10 10:42 AM:

OK thanks for expressing your interest in this as well.

I have discussed it around Strava for more opinion, but this will stay as-is.

Strava Support Team

Christian Mace, Oct 10 10:31 AM:

Hello again,

"I think that maybe Strava could offer the option to toggle between moving time and elapsed time for analyzing their activity.". Of course, that would be perfect and would also imply to label correctly. Labeling correctly is the first step and after the next perfect step would be to offer stats in actual/real average "pace" and in average "moving pace" like you propose. I'm not saying that moving pace is useless, I'M sayin that you could want the real pace.

Thanks for answering and for looking to be in a listening mode... but I understand that there is no plan to change anything about this labeling issue (that is a BUG: two set of data for the same variable...)


EJ Noreika, Oct 10 10:15 AM:

I think that maybe Strava could offer the option to toggle between moving time and elapsed time for analyzing their activity. At the same time, I'm living in an urban area and am a fan of the moving time calculations. I am frequently stuck at stop lights and busy intersections where my elapsed time-pace would suffer significantly.

Blaine Browning that you referenced has already filed tickets regarding these distinctions as well, but there is still no plan to change the way this is displayed.

Strava Support Team

Christian Mace, Oct 10 09:55 AM:

It is not a question of what people would like to see, but a question about the label of the data of what people want to see and the inconsistencies about those (tag a run as a "race" shouldn't change the value of the same variable "race" and even "moving pace" is not "pace"...??). If the "vast majority of [y]our runners" want to see moving pace, are you sure they also want it to be mislabeled as "pace" ?

If the "vast majority of [y]our runners" want moving pace to be labled as pace... it is probabley becuase they don't know the difference between both... if you explain them, they would agree, I'm sure, about a correct labelin of their stats. You don't think?

Thanks for the answer.


EJ Noreika, Oct 10 09:45 AM:

Hi Christian,

There are a few people who have brought this up, and I'm sure you've seen the discussion on the forums.

At this time we have no plans to change the way we display pace. We feel that this the way the vast majority of our runners want pace to be displayed. This is supported by the fact that we have heard countless number of requests asking us to improve the way that we detect and remove resting time so that we can accurately display moving pace without any resting time.

If your activities (or those of others on the forum you've mentioned) are inaccurately detecting resting time when there shouldn't be any, then this is a different issue and something that should be addressed on a one-off basis.

Strava Support Team

Christian Mace, Oct 09 12:38 PM:

I cannot say it better than Blaine Browning, so I recopy the bug apparently already exposed to you:

"Both on the web and mobile versions of Strava:

1) The overall data of a run shows a moving pace labeled as "Pace".

2) The mile splits are labeled as "Pace" but have the values of moving pace.

3) When a run is marked as a "Race", the labels of "Pace" stay the same and the values change from moving pace to pace. This is called overloading and it is erroneous to label 2 different sets of data as the same thing. Similar to creating a field called "Money" and alternating the value between 10.00 and 13.00 not knowing what currency it is and then swapping the values arbitrarily.

For these 3 reasons, the mislabeling of Pace in Strava is erroneous and a bug and needs to be fixed."

October 10, 2014, 12:58 PM
User photo
Blaine Browning

@Vegard re: "a big blunder from a UX perspective"... I too am a Senior Software Engineer and also believe in my professional opinion it is a poor decision for Strava to be mislabeling data such as moving pace.

@Christian  its clear EJ from Strava is not reading our concern's correctly. My ticket I sent yesterday and the one you copied and pasted and sent has absolutely nothing to do with the other issue of showing BOTH moving pace and pace. Re-read what we wrote to Strava in the ticket and then read what EJ wrote back. My ticket had nothing to do with detecting resting time and showing moving pace vs actual pace. It had to do with accurately labeling moving pace as "Moving Pace" which he did not address. Why would Strava insist on not accurately labeling moving pace as "Moving Pace"? Right next to it is a "Moving Time" field but they mislabel moving pace as "Pace" and as a result, people believe that is their actual pace which may at times be much faster than their actual pace.


I also believe Strava should be showing both Moving Pace AND Pace, but my first and simplest request is to have Strava accurately LABEL moving pace as "Moving Pace".



October 10, 2014, 12:44 PM
User photo
Christian Mace

I wrote STRAVA that:

  • I cannot say it better than Blaine Browning, so I recopy the bug apparently already exposed to you:
  • "Both on the web and mobile versions of Strava:
  • 1) The overall data of a run shows a moving pace labeled as "Pace".
  • 2) The mile splits are labeled as "Pace" but have the values of moving pace.
  • 3) When a run is marked as a "Race", the labels of "Pace" stay the same and the values change from moving pace to pace. This is called overloading and it is erroneous to label 2 different sets of data as the same thing. Similar to creating a field called "Money" and alternating the value between 10.00 and 13.00 not knowing what currency it is and then swapping the values arbitrarily.
  • For these 3 reasons, the mislabeling of Pace in Strava is erroneous and a bug and needs to be fixed."

And they answered that:

Hi Christian, There are a few people who have brought this up, and I'm sure you've seen the discussion on the forums. At this time we have no plans to change the way we display pace. We feel that this the way the vast majority of our runners want pace to be displayed. This is supported by the fact that we have heard countless number of requests asking us to improve the way that we detect and remove resting time so that we can accurately display moving pace without any resting time. If your activities (or those of others on the forum you've mentioned) are inaccurately detecting resting time when there shouldn't be any, then this is a different issue and something that should be addressed on a one-off basis. Best, EJ,Strava Support Team"

What I responded to that:

"It is not a question of what people would like to see, but a question about the label of the data of what people want to see and the inconsistencies about those (tag a run as a "race" shouldn't change the value of the same variable "race" and even "moving pace" is not "pace"...??). If the "vast majority of [y]our runners" want to see moving pace, are you sure they also want it to be mislabeled as "pace" ?
If the "vast majority of [y]our runners" want moving pace to be labled as pace... it is probabley becuase they don't know the difference between both... if you explain them, they would agree, I'm sure, about a correct labelin of their stats. You don't think? Thanks for the answer."
October 10, 2014, 10:00 AM
User photo
Vegard Helland

I don't know if anything has changed behind the scenes, but my latest runs have pretty much the exact same moving pace and actual pace.

However, the idea of labeling two different sets of data with the same label is a big blunder from a UX perspective. As a web developer, this is quite frankly a very bad decision from the Strava team in my professional opinion. This whole issue would be a lot less annoying if they labeled the data correctly in their user interfaces. 

It seems Garmin devices are most prone to a bid time difference between moving pace and actual pace though. Take a look at this run as an example:

Distance: 22km,

Moving time 1.08.11

Best estimated Half marathon effort: (21.1km): 1.11.25,

Actual elapsed time: 1.15.09

Moving time in this scenario is extremely misleading. 

October 9, 2014, 11:50 PM
User photo
Christian Mace

Hi Blaime:

I send a request to Strava team and I literally copied what you wrote, because it is a bug and you said it perfectly. I guess more people will do that and more Strava team will listen... Thanks for that thread:

  • "This ticket is being opened to track Strava's response, fixing and resolving the bug of erroneously labeling moving pace as "Pace".
  • Both on the web and mobile versions of Strava:
  • 1) The overall data of a run shows a moving pace labeled as "Pace".
  • 2) The mile splits are labeled as "Pace" but have the values of moving pace.
  • 3) When a run is marked as a "Race", the labels of "Pace" stay the same and the values change from moving pace to pace. This is called overloading and it is erroneous to label 2 different sets of data as the same thing. Similar to creating a field called "Money" and alternating the value between 10.00 and 13.00 not knowing what currency it is and then swapping the values arbitrarily.
  • For these 3 reasons, the mislabeling of Pace in Strava is erroneous and a bug and needs to be fixed.
  • This ticket will be open until Strava fixes this on both the Web and Mobile apps and starts labeling moving pace as "Moving Pace" and the actual pace as "Pace" and not overloading the meaning of the label "Pace".
October 9, 2014, 12:31 PM
User photo
Blaine Browning

In regards to my last comments about the erroneous and misleading labeling of moving pace as "Pace" and using that same label of "Pace" for actual pace (when marked as a Race), I opened a ticket with Strava and received their typical response of this is the way we're doing it and its not a bug. Again, not listening to customers concerns or fixing their own fundamental data bugs. This is so incredibly fundamental and basic - to simply properly label "Moving Pace" as "Moving Pace" and not use the same label of "Pace" to mean BOTH "Moving Pace" and "Pace". Blows my mind Strava does not see this as an issue they want to address - in fact say "it's an intentional UX decision". The entire point of tracking your runs as a data athlete is to correctly track and present that data for your's and other's clarity in your training. Data becomes useless otherwise. Essentially, Strava massages your data, mislabels it and misleadingly treats it as accurate and clear. And they want you to pay a monthly fee for that.

So, not only will Stava not even show you your actual pace unless you mark a run as a "Race", they will not even label moving pace correctly as "Moving Pace".



"This ticket is being opened to track Strava's response, fixing and resolving the bug of erroneously labeling moving pace as "Pace".

Both on the web and mobile versions of Strava:

1) The overall data of a run shows a moving pace labeled as "Pace".

2) The mile splits are labeled as "Pace" but have the values of moving pace.

3) When a run is marked as a "Race", the labels of "Pace" stay the same and the values change from moving pace to pace. This is called overloading and it is erroneous to label 2 different sets of data as the same thing. Similar to creating a field called "Money" and alternating the value between 10.00 and 13.00 not knowing what currency it is and then swapping the values arbitrarily.

For these 3 reasons, the mislabeling of Pace in Strava is erroneous and a bug and needs to be fixed.

This ticket will be open until Strava fixes this on both the Web and Mobile apps and starts labeling moving pace as "Moving Pace" and the actual pace as "Pace" and not overloading the meaning of the label "Pace".



"Hello Blaine,

  • Thanks again for your feedback. I understand your point. However, we do not see this is a bug. It's intentional and is a UX decision. So, as stated previously, I'll be sure to share your thoughts on this with the team.

    Strava Support Team

    October 09, 2014 10:52 AM"
    October 9, 2014, 12:05 PM
    User photo
    Tom B.

    I quote Strava:

    "If the runner doesn't use the pause feature on their Garmin device, (Strava) will automatically detect when the runner is resting, and (Strava) will calculate moving time and pace using only GPS data. "

    "The moving threshold is anything faster than 30 minute mile pace for running activities."  (My opinion: this threshold is useless because if the GPS Data is not perfectly reliable then any GPS dropouts will be seen as stops) 

    "If the runner chooses to pause their run activity on their Garmin device, we will honor that choice and represent moving time according to the time and pace shown on the GPS device."

    So this means purposely stopping or pausing the Garmin (auto pause doesn't seem to count). This will force Strava to not auto detect pauses and give you moving time as elapsed time (minus any manual pauses you made) 

    October 9, 2014, 2:34 AM
    User photo
    Mark Jacobs

    I've also found pausing my forerunner 110 for a second a couple of times during the run stops the ridiculous moving times calculations.

    October 9, 2014, 2:19 AM
    User photo
    Steve Marr

    I have not posted in this thread for quite some time as frankly it was winding me up. How Strava can take perfectly good accurate data from devices and then CHOOSE to change it to make it inaccurate and then claim that “there is nothing they can do about it”, and “it’s just the way the system works”... I will never know...

    Anyway, I am not writing this post for the good of Strava, I am writing this for the benefit of those who like me find this moving time/pace thing extremely frustrating and ridiculous.

    As with everything this might not apply to all, but I use a Garmin Forerunner 110, and I suffer with consistently bad and unacceptable variances between moving and actual pace/time... but in the last couple of weeks I have made a bit of a discovery...

    Now that the nights are drawing in here in the UK I am once again running in the dark and so having to use the light on my watch to see what’s going on. A couple of weeks ago when I was getting tired instead of pressing “light” I accidently pressed “stop”. Realising my mistake I quickly pressed “start” again and continued my run.

    Then I got to thinking about some of the comments on this thread and in particular the question as to whether pausing your watch during runs for some reason forces Strava to present the actual data rather than present its own fantasy version of the truth.

    I had previously dismissed this theory as I’m sure in the past I have paused my watch and it has not made any difference, but nevertheless it got me thinking. As on this occasion I had accidently paused my watch (probably for only a second) maybe I should just try it once more and see what happens. So during this hour long run I have now paused my watch a couple of times and probably lost just 2 or 3 seconds.

    When I got home I was then happy and surprised to find that my “moving” time was virtually the same as my “elapsed” time... This could of course have been a fluke as every now and again this does happen, so I thought I would try this out on my next couple of runs to see what happened.

    The next run I went on I added a couple of pauses one at about 1/3 distance and one at about 2/3 distance and I made sure they were at least a couple of seconds long to look like true pauses. Again the “moving” time/pace was very representative and was pretty much identical to Garmin Connect.

    Last night I thought I would try and test the theory once again, and this time push it a little bit to make this practice a bit more practical. So within probably 100m of my home I had done a quick stop-start-stop-start and then just carried on as normal for the next hour. I am very happy to report that once again the results on Strava were almost identical to Garmin Connect.

    So there you go... I still can’t believe that Strava has completely ignored this thread for such a long time, and I pat those on the back who have cancelled their premium subscriptions in protest. I am hoping that I may have found myself a simple little fix for this stupid problem, and hopefully this could work for some of you as well.

    October 9, 2014, 1:39 AM
    User photo
    Mark Jacobs

    Wow, this is a joke.


    • 10.1mi
    • 1:23:33
       Moving Time
    • 8:18/mi
    Elapsed Time
    11 minutes difference between elapsed and moving time on a run where I didn't stop??
    October 1, 2014, 1:35 PM
    User photo
    Ian Sadler
    Frankly I'm passed caring about Strava calculating moving time incorrectly. But please just add a simple toggle button to display elapsed time if you want to when sharing your data. Flicking to Race only alters the headline display to elapsed time, it still uses moving time when sharing.
    October 1, 2014, 1:15 PM
    User photo
    Mark Jacobs

    This is really terrible. Had 7 minutes of stopped time on a run in a park where I didn't stop at all, this needs to be optional I just want to see my proper times without having to switch every session to race. Really doesn't work well for runnners.

    September 30, 2014, 1:38 PM
    User photo
    Stanislav C.

    I suspect the problem lies much deeper so this isn't an easy fix for Strava engineers. My impression from looking at numerous charts is that Strava does some filtering of data points when GPS tracks are uploaded and throws away points that too close. Then activity charts depends on these "filtered" track - if you look carefully you can see moving time on the x-axis and all segments where you weren't moving (like aid stations) are not showing up on the charts. Also I suspect the best estimated results for various distances depending on these "filtered" tracks, etc. This would be a good explanation of getting a number of best estimated efforts on fairly slow runs in mountains. So I think the problem is much more fundamental.

    September 27, 2014, 2:15 PM
    User photo
    Calle Gothnier

    Agreed, and I am also suspending my subscription.

    September 21, 2014, 11:45 PM
    User photo
    Tim Sargent

    It would be really useful if on Strava we could see on our activities elapsed time and average page.  It is really amazing that it is missing such as basic feature that every other activity tracking system has.

    September 21, 2014, 11:39 PM
    User photo
    Blaine Browning

    It has been over a year since I started this thread and Strava has yet to fix the bug related to Pace / Moving Pace as I originally and repeatedly brought up. There has been significant discussion on this thread about the confusion over the fundamental data associated with our runs, how Strava alters that data, labels it and presents it.

    This thread is now huge and over a year old. Strava's response is to ignore its customers and tell them what they want - not listening to what we want but telling us what we want. This is a quote from this thread in November 2013 from a Strava employee:

    "At this time we have no plans to change the way we display pace. We feel that this the way the vast majority of our runners want pace to be displayed."

    - Travis Robison

    It is now very clear that the vast majority of runners want to see there actual pace values without either; 1) tagging a training run as a Race, or 2) executing a workaround such as starting and stopping your watch to avoid Strava's moving pace algorithms to kick it.

    Additionally, as I pointed out over a year ago at the start of this thread and repeatedly in this thread and from customer support tickets is that regardless of which data Strava is showing, their labeling of moving pace values as just Pace - is a BUG. Strava and fellow runners - there is no way around this. The first thing to be fixed is for Strava to correctly label their data fields and NOT OVERLOAD them. When a run is tagged as a Run or a Race, the Pace values (overall and mile splits) toggle between Moving Pace (for a Run) and Pace (for a Race), yet the LABEL is still just Pace. This is overloading the data fields and a BUG.

    This is the equivalent of Amazon having a field called "Money" for a product, and the value of that field arbitrarily alternating between "10" and "13" and not knowing what the currency is; USD, Euro's, etc.

    I am raising awareness of this bug again by attaching two screenshots of a recent trail run/hike where I stopped for breaks. You can see that when the run is toggled between Run and Race, the pace values change, yet the pace Label is the same! Moving Pace values need to be labeled as Moving Pace! Not Pace! This is what Garmin does btw.

    This pace labeling bug on both the web and mobile apps is the first thing that needs to change. Secondly, to satisfy everyone (who are paying you Strava btw), we need to see BOTH Pace and Moving Pace values displayed and clearly labelled on the same screen without altering the tag of the run.

    I have suspended paying for Strava until I see this has been fixed and Strava starts to listen to its customers and fixes outstanding fundamental data bugs. I urge others to do the same. Over a year is too long for Strava to ignore this issue and its customers.

    Please see the 2 attachments on this post for clarification of this pace labeling bug. 

    September 19, 2014, 4:09 PM
    User photo
    phillysports 20

    I don't have any hard data, it just seems as though the discrepancies are much smaller. I had been marking all my Strava runs as "races" to eliminate this issue, but I haven't had to do that much since the sync feature went into effect.

    September 18, 2014, 7:48 AM
    User photo
    Reid Bremner

    @phillysports 20: Agree that the new feature for syncing is great but this is just an automated way of sending data, it shouldn't change the data itself. I'd be curious if you have any examples of how improvements may have been made?

    September 18, 2014, 7:40 AM
    User photo
    phillysports 20

    For me, the recent update where Garmin Connect data automatically syncs to Strava has significantly helped this Moving Time issue. The data is not always perfect, but it's much closer to reality.

    Just wanted to add my two cents and thank Strava for implementing this time-saving feature!

    September 18, 2014, 7:35 AM
    User photo
    Tom B.

    @Calle: Yep totally agree. 

    I was just wondering if this "hack" works. It remains to be seen.

    September 18, 2014, 1:52 AM
    User photo
    Calle Gothnier

    @Tom B: I wonder why I would even have to bother? Seems easier to take my data elsewhere.

    I press start, I run for a while, I press stop. Why would I have to remember doing anything else to get a proper time?

    September 18, 2014, 1:47 AM
    User photo
    Tom B.

    @Calle: I understand. So in theory you can turn auto-pause OFF and then just to "trick" Strava in to using elapsed time as moving time just manually push the pause button once (then resume of course). Either at the begining or end of the run so Strava has at lease one pause and hopefully "honor that choice and represent moving time according to the time and pace shown on the GPS device".
    I wonder if that would actually work?

    September 18, 2014, 1:34 AM
    User photo
    Vegard Helland

    But what about anything other than a Garmin device? I use a TomTom Multisport watch, and for a run I did a few weeks back, Strava still shaved a few seconds off the moving time even though I used the pause function. If this algorithm is specific to Garmin devices, all other devices should be exempt for Moving Time so that we get proper timing on our trail runs.

    There's not many days I drop below 30min/mile at any point in a run, but Moving Time always shaves from a few seconds up to almost a minute off my training runs. 

    September 18, 2014, 1:28 AM
    User photo
    Calle Gothnier

    I don't think there's any difference between a pause from a button press or from a software condition, a pause is a pause is a pause. But when Strava tries to detect resting and excludes that, it effectively becomes the same thing as if I had turned on Auto-Pause on my watch. Point is, I actively choose to turn Auto-Pause off, because I want pauses in my workout to be included as well. 

    But Strava dishonors my setting and does some auto-pause detection of its own.... with moderate success, it seems.

    September 18, 2014, 1:28 AM
    User photo
    Tom B.

    The way I understand it is it's not talking about the AUTO-Pause feature. It's just refering to pausing it manually. So actually pushing the pause button on the watch. 

    So this definition needs to be defined more clearly. What is the "pause feature" mentioned in the definition? Does AUTO -Pause count? or Just manual pause?

    There are 3 possibilities:

    Turn Auto-Pause OFF and push the pause button once
    Turn Auto-Pause ON and push the pause button once
    Turn Auto-Pause ON and no need to push button

    September 18, 2014, 1:18 AM
    User photo
    Calle Gothnier

    On my Garmin watch I have a feature called "Auto Pause", where it pauses the recording when the pace is below 30 minute per mile (for example). 

    Interesting. If I understand the Moving Time definition above correctly, this means that if I turn it on in the watch I will get only the moving time on Strava.

    And if I turn it off in the watch, Strava will simulate that I had it turned on by doing exactly what my watch would have done if I had turned it on.

    Now that was a new definition of 'honor that choice'.

    September 18, 2014, 1:05 AM
    User photo
    Reid Bremner

    No, it doesnt, it wont reflect that time for the duration of the pause but will still exclude other very slow segments (those often associated to big technical climbs)

    At this point I am beyond frustrated with Strava's concept of moving time as it is time and time again incorrectly reflecting the time and moving pace of different activities for a large number of us who participate in the trail running community. Its basically negated the value of any of these stats, especially on mobile devices.

    There are a number of people now referring to Strava "Hero Mode".... because it makes average runs look great....

    September 18, 2014, 12:51 AM
    User photo
    Tom B.

    This is from Stravas definition:

    Moving Time

    The moving time feature on Strava is used for all running activities that don't depend on fair competition (races and segments). We calculate moving time in two ways.

    • If the runner doesn't use the pause feature on their Garmin device, we will automatically detect when the runner is resting, and we will calculate moving time and pace using only GPS data. The moving threshold is anything faster than 30 minute mile pace for running activities.
    • If the runner chooses to pause their run activity on their Garmin device, we will honor that choice and represent moving time according to the time and pace shown on the GPS device.

    So as Elle mentioned already just push the pause button on the device at least once and Strava should not add pauses automatically. Can anyone confirm that this works?

    September 18, 2014, 12:32 AM
    User photo
    Joanna Bridge

    Ditto.  I start my run and I don't stop.  Strava consistently takes off a minute for my moving time.  Does it think I'm going too slow, thereby thinking I'm not moving for a minute?  My slowest pace total (I run with Nike+ app, too) is ~12 min/mile, which is not THAT slow.

    September 5, 2014, 4:18 PM
    User photo
    Adam Smith

    This should be fixed...why should my pace vary depending on activity (or deviate in any way from ACTUAL)? Setting an activity as "race" is a sorry work around to correct a faulty algorithm. Come on guys.....I second the complaints of most of everything mentioned above.


    September 1, 2014, 11:03 PM
    User photo
    Christian Mace

    I agree: "Strava uses Moving Pace for Mile Spilts and NOT YOUR ACTUAL PACE."

    August 21, 2014, 8:29 AM
    User photo
    Karl Wallevik


    I am generally very happy with Strava, but I do agree with the majority in this thread regarding "moving time" being used to calculate pace, splits etc. Personally I have no interest in my "moving time" - I want "elapsed time" to be the deafult for my training runs as well as my races. When "moving time" is used to calculate pace/splits I can't really compare my training runs in a meaningful way - this is especially true for my uphill "runs" where my pace is often ... embarrassingly slow. I would also prefer to not have to flag my training runs as "races" in order to get splits and average pace based on "elapsed time".

    Best regards,

    Karl Wallevik

    August 14, 2014, 4:16 AM
    User photo
    Elle Anderson
    Community Support

    @Adam - great catch on a possible bug. I'll document it right away (something I can do with a quick turnaround!) Indeed, your profile stats should count total elapsed time if that is what is chosen on the run page. 

    The rest are all good points raised here. I continue to pass them along...

    August 1, 2014, 3:56 PM
    User photo
    Adam Wenborn

    Another bug (as I see it anyway) is that even if a run is tagged as a race, "Moving Time" is still used towards all of your weekly/monthly/annual/all-time totals.

    Strava is robbing me of precious minutes of exertion every time I go out running!!! Not such an issue with regular runs, but for cases like Armand's above where he's lost 12+ hours (and >50%), again it makes a mockery of everything Strava is trying to achieve.

    As a side-note, I noticed Garmin Connect's moving time algorithm doesn't seem to have these problems, so it is a problem that can probably be fixed with a little attention. For example, times from Sunday's half marathon with identical file uploads:

    Garmin Connect:    Elapsed Time - 1:40:17     Moving Time - 1:40:16

    Strava:                      Elapsed Time - 1:40:16     Moving Time - 1:38:38


    To be honest, I suspect the reason none of these requests get any attention is because they're busy reworking the whole interface. That way they can have a snazzy "relaunch" that gets loads of attention on blogs and the like, rather than just fixing the simple issues that affect people's day-to-day use (or in my case for running non-use) of the site. Hopefully, at least some of the points raised here might get some sort of resolution at some unspecified point down the road.

    P.S. Congratulations Armand, epic run!

    July 29, 2014, 4:28 AM
    User photo
    Adam Engst

    I finally got around to reviewing Strava for TidBITS, and while my opinion of the service is overall positive, I was forced to qualify my recommendation for people who care about data accuracy. Strava's reliance on GPS track data, which is guaranteed to be inaccurate at least some of the time, is just a poor design decision. I hope a little more public focus on the problem will encourage Strava's development team to reconsider their approach.

    July 28, 2014, 7:08 AM
    User photo
    Steve Marr

    I think I have finally seen a benefit to “moving pace”... Inspired by the Commonwealth games I went out yesterday to try and break my PB for 5 miles... Setting off a bit over-enthusiastic I blew up after about 2 miles, but struggled on eventually stopping my Garmin Forerunner 110 after 5 miles at 30:55... Unfortunately that was a fail for the PB :-( ...

    Getting home a bit despondent, I downloaded my run to Strava, only to find that rather than displaying the truth, Strava was broadcasting that I had just run 5 miles in 29:18... Fantastic... I knew I was getting faster... Thanks Strava!

    PS - Sorry for making a joke on this thread... But lets face it that’s what moving pace is on Strava.

    PPS - Armand D – Well done on your 120km epic run... A cracking achievement in real time let alone fantasy Strava time!

    PPPS – Please can someone stop me posting on this thread... I’m even boring myself now... Come on Steve, it is what it is, just accept it, move on and get over it...

    July 28, 2014, 3:09 AM
    User photo
    Armand D.

    Here's an another example of why Moving Time for especially trail is a terrible concept. This run was 120km of hard jungle, swamp and mountain running. My finish time was 24h, Strava graciously gave me an 11:46. The winning time was just under 22h so on Strava I won with a 10h lead...

    July 27, 2014, 6:29 AM
    User photo
    Elle Anderson
    Community Support

    @Damien - helpful indeed. Thanks for adding your insights! 

    @Steve - no worries, thanks for the extra examples. 

    Good tip @Tom! 

    July 22, 2014, 4:33 PM
    User photo
    Tom B.

    If anybody is interested, I might have found a work around to this problem with Strava adding pauses. I've found a program that allows you to edit raw .gpx files. I was able to delete the duplicate entries that show little or no movement. This does not change the total time or distance but only the moving time and hence the pace is corrected.

    After you download the program you can load your gpx from garmin and then under the menu "Positions" choose "delete duplicate positions" and then enter a value in meters under "Select all redundant positions with a threshold of  XX meters" hit "select" and then hit "Delete selected positions". Close that window and then under "Positionlist" choose "Export to file" save it and then upload to Strava. You should have a more accurate moving time

    In my test file tried using different thresholds of from 0.5, 1, 1.5 and 2 meters. Basically the higher the threshold the closer the moving time is to the elapsed time. At 2 meters I got a fairly close pace to what GC gave me for the run. I didn't try higher thresholds than 2 but perhaps someone wants to play around there.
    Basically it shouldn't affect total time and distance, as i said. But I imagine that other problems could arise for example heart rate sensor data could get messed up or have gaps if you remove to many trackpoints

    Disclaimer: use at own risk ;)

    July 22, 2014, 7:39 AM
    User photo
    Steve Marr

    Hi Elle... Me again (sorry!)

    I have made my opinions clear on this thread (more than once) and so I am not going to do it again. At the end of the day I am just a user and my opinion is no more important than anyone elses... Also I feel like I am shooting the messenger (By messenger I mean you Elle and I am sorry for that :-) )...

    So I am not going to express my opinion... But from time to time I might just highlight the odd example run... Hopefully Elle you could be kind enough to pass these examples on to your developers so that they can make up their own mind as to whether or not they are displaying data in the best way.

    Saturday’s run as displayed on my Strava Android app:
    Distance = 15.1km
    Time displayed in Strava = 59:16

    Achievements within that run:
    PR for 15km
    Time displayed in Strava = 1:00:50

    If they would like to view the activity they can here:

    As I said... I’m going to refrain from giving opinions... But would just like to point out that a segment of this run appears to have taken longer than the entire run???
    (And no, I did not stop for a break anywhere)

    July 22, 2014, 2:59 AM
    User photo
    Damien Gooden

    Hey Guys,

    I am a brand new user (just signed up and imported all my data from a competitors product today) and was totally flummoxed by moving time (which led me to this thread)

    Elle - is it possible to re-frame this to your product team/developers perhaps?

    Rather than talking about bugs or worrying about how the moving time is calculated - can you suggest a functionality change that:

    1. Removes the existing link between run type (Run, Long Run, Workout, Race etc) and the time field used in calcs (Total Elapsed TimeTimer Time or Moving Time) which seems somewhat arbitrary

    2. Allows the user to select which time field should be used in calcs per logged event

    3. Allows the user to set default time fields per run type (as these will most often not need to change per logged event per user) which when you sign up is setup as the system works now.

    I think as a functionality change this will:

    1. Allow all those who like how it works now to have it keep working that way

    2. Provide a mechanism for all those who don't like the way it is now to change it.

    i.e. make everyone happy.



    July 20, 2014, 2:05 AM
    User photo
    Adam Engst

    The fact that Strava pays attention ONLY to GPS track points, and not anything else, tripped me up in a race situation recently. I ran a 5:09 1600m race on a track, but Strava reported it as a 5:07, even after I marked the activity as a race. When Strava support responded to my query, they noted that the GPS track points for start and finish were separated by exactly 5:07, not 5:09. What that means is that the Garmin 620 failed to pick up satellite, or at least chose not to write a GPS track point, for 2 seconds at the start of the race. It had been on and locked on satellite during my warmup, so it wasn't a power-on lag. Presumably just GPS flakiness.

    What I'd suggest is that the easiest solution to all this is simply to let the user overwrite the time and distance fields. That way, if there's any error (GPS or human), it's easily rectified, and the user can be sure that the data matches what is known from external sources (such as an official race time or distance). Failing that, the only real solution is to delete the activity entirely and create a new one that has the correct time and distance (but no other information whatsoever). That's a lot of extra work for the user, and a bad user experience, so allowing data edits would seem to be a much better approach.

    July 18, 2014, 11:25 AM
    User photo
    Elle Anderson
    Community Support

    Thanks for adding your support Calle! 

    July 18, 2014, 10:49 AM
    User photo
    Calle Gothnier

    @Elle, why would you deliberately design something that depends on totally accurate GPS positioning, when that is something that never will be achieved? What are the design goals behind moving time?

    I made a run with my Samsung S4, which for some reason started to double-log coordinates or something. The GPS track looked good but my pace became 2:15 min/km, which is somewhat above my running abilities. I had to mark it as race in order to make it appear reasonable, which isn't very good either. This is a somewhat normal GPS error, and your algorithm totally failed. Or would you say it was correct?

    Even top-notch Garmin 620 struggles whithout a clear sky view.

    Why not just use elapsed time, since that would be most natural anyway? And respect any manual start/stop actions of course.

    July 18, 2014, 10:08 AM
    User photo
    Elle Anderson
    Community Support

    @Steve, we've worked hard on our formula for moving time (and thus moving pace) for runs on Strava.  It is our best attempt at this time and for a large percentage of activities it works as intended/designed. I would phrase your question a bit differently - we don't insist on defaulting to "moving pace", it is just how our run analysis was designed by the Strava team. Nothing is set in stone, and input like yours is part of a feedback trend that is being fed back into the development cycle. We are listening, and hope we can consider the suggestions discussed here going forward. 

    July 16, 2014, 2:17 PM
    User photo
    Steve Marr

    Elle, thank you for responding as it is nice to know that this thread is not being completely ignored...
    But I’m confused...

    I think I’m right in surmising that in Strava “actual pace” works fine for running, but “moving pace” has problems...

    You said above:
    “GPS accuracy is a much larger issue for run data that it is for cycling data because of the lower speeds, and it is an obstacle that Strava has not yet been able to tackle”
    “I agree that tackling GPS accuracy is imperative for quality run data!”

    So if you think that quality run data is important, but you are aware that Strava can’t calculate “moving pace” accurately... Then why do you insist on defaulting to “moving pace” (which you can’t calculate correctly) rather than “actual pace” (which you can calculate accurately)?

    If your development guys do actually manage to crack “moving pace” for running at a point in the future, then yes there would be an argument for using it... But surely until such a point as they can get it right they should default to a data field that is accurate i.e. “actual pace”?

    July 16, 2014, 6:52 AM
    User photo
    Vegard Helland

    I must say that after I got a TomTom MultiSport GPS watch, the issue haven't really been noticeable at all. This watch has a 1-second GPS tracking interval by default and it seems to track my runs quite well, even in places where my phone with Strava app fell out briefly and properly messed up the moving time calculations. 

    July 15, 2014, 12:34 PM
    User photo
    Elle Anderson
    Community Support

    A really great discussion on here - thanks to all of you for your insights and feedback about both our moving time calculation and it's accuracy issues, and the request to calculate pace from total time instead of moving time for all run types. 

    I particularly liked @Tom B.'s comments regarding GPS coordinates that struggle with accuracy issues and cause false resting time to be detected. GPS accuracy is a much larger issue for run data that it is for cycling data because of the lower speeds, and it is an obstacle that Strava has not yet been able to tackle. I agree that tackling GPS accuracy is imperative for quality run data! A quick note to add - even with "strong" GPS devices, running on trails with heavy tree cover or in cities with tall buildings causes accuracy issues with the GPS signal. 

    @Reid Bremner's comment is also helpful and true: If you have a Garmin run device, turn off auto-pause, and use the manual "Stop/Resume" button at least once during your run, the Strava will NOT overwrite your time data with it's algorithm for detecting resting time. Instead, Strava will display the time data according to the "timer time" of using the Stop/Resume action. In theory, you could use this button for a brief instant at the beginning or end of your run and then you would see pace times that reflect your total time. 

    @Adam - I'm aware of that forum regarding run cadence. No action yet - but I'm a supporter of getting that fixed! Should be plenty easy. 

    As always, I'm sharing this feedback with our Product team. Thanks for your continued feedback! 

    July 15, 2014, 11:12 AM
    User photo
    Tom B.

    I DO think that the foot pod makes a difference. But I'm only basing this on one run so far.

    Strava only had a 10 second pause in my last run with the foot pod activated. This is pretty much in line with the results on GC.! But I don't know if this improvement is related to the new Garmin Forerunner 220, or just the foot pod -- perhaps both. Fact is, the older runs had pauses of a minute or more over a 30 minute run. So I can live with 10 seconds. 

    I will definitely keep looking at the results. Maybe I'll test with the foot pod on one of my other GPS devices that were getting bad results (Edge 510 and smartphone) and see if there's an improvement there.

    July 14, 2014, 2:45 AM
    User photo
    Adam Wenborn

    Ok thanks for the reply. Sorry to get off topic, but I just wanted to know if it'll help smooth out big spikes in pace seen when GPS reception is lost as is often the case on some of my regular routes. Sounds like it's worth a try at least.

    I've heard of the the 'one-foot-cadence' issue on Strava before and unsurprisingly there's another support thread for that, which has also resulted in absolutely no action!

    July 14, 2014, 2:28 AM
    User photo
    Tom B.

    So I just looked at a run I did with my new Garmin Forerunner 220 and the cadence or steps per minute from my foot pod are recorded. However only for the foot that the sensor is on. -_-
    GC shows the correct doubled amount. So i guess we just have to double the amount to get the right cadence. 

    July 14, 2014, 2:22 AM