Feedback on Run Tags and Moving Time/Pace Calculation


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.






  • 공식 댓글

    There is a great, related discussion on specifying moving time or total elapsed time for activities. Please feel free to vote and leave your feedback there as well. 

  • Seriously. I ran a1:30:06 1/2 marathon, which is a PR and all.... And my friends start flipping about the 6:23 pace that Strava showed. (Which would've won me the race.)
  • Strava Users - 

    To elaborate and test what I mean by point #2 above, that Strava is misleadingly displaying Moving Pace mile splits vs actual Mile Splits - try this experiment:


    1) Run 5 miles on level ground @ a 9:00/min pace for each of the 5 miles - exactly

    2) Keep watching your GPS watch to ensure you are running at a consistent 9:00/min pace

    3) For miles 1, 2 make sure the watch splits are at 9:00 min miles

    4) At 2.5 miles, stop, dead still in your tracks for 2 minutes, then continue and fniish the 3rd mile at a 11:00 pace according to your GPS watch

    5) Continue with a consistent 9:00 pace splits for miles 4 and 5.

    6) Upload to Strava and view your Mile Splits

    Strava will show your miles splits as ALL 9:00 paces even though you were stopped still for an entire 2 minutes. They should show, mile 1: 9:00, mile 2: 9:00, mile 3: 11:00, mile 4: 9:00, mile 5: 9:00.

    Now, change your type of Run to a Race. Mile Split 3 should now read 11:00 pace. Strava changed the splits from Moving Pace to Actual Pace when labeling the run as a race. Regardless, the splits are not labeled as Moving Pace or Actual Pace, leading to confusion.

    Odd - isn't it? Especially with ZERO labeling of using Moving Pace vs Actual Pace - and an inconsistency of using one or the other without notifying users!


    Strava - please respond...

  • Agree completely.  Already wrote to Strava customer support about it.  Competing apps have auto-pause settings.  Strava has nice features that could make it preferable to those competing apps but if it can't keep accurate time then it's altogether useless.  As it is, I use Runkeeper which has auto-pause setting.  Premium version costs less than half of Strava per year.  Get with it Strava—it's not rocket science to add an on/off switch in the settings.

  • Adding my two cents (which is in line with all other comments).

    So far moving time hadn't bothered me... 10s on a 1h run didn't change my stats significantly. But today 37min run became a 34min run (with moving time). My splits aren't making any sense. I don't even see where Strava could have removed time on my run (20s on two traffic lights, sure, 3min, no).

    Of course, I can take this all off by making it a race... but it wasn't. +1 for the on/off switch on moving time.

  • I've given up waiting for Strava on this issue.  Maybe Strava's market is people who want to exaggerate their accomplishments.  I appreciate the above comment that 10 sec. in 1 hr. is not significant, but what's the point of adding any inaccuracy?  I can't use "race" because it's not on the free version and I won't upgrade if the free version doesn't work right.  So I've switched to RunKeeper and upgraded to the Elite version (which is only 1/3 the cost of Strava anyway).  Bye bye Strava.

  • I submitted a support ticket to Strava to respond to this thread and issue that Strava uses Moving Pace for Mile Spilts and NOT YOUR ACTUAL PACE.

    I escalated the issue to the Customer Support manager, Travis Robison, and this is his response:

    "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


    Obviously, based on this thread and another thread with customers responses, this is incorrect. people DO want their REAL PACE - Strava's response is to tell their customers essentially - "no that's not what you want." 




    If you are reading this and agree Strava should supply the actual data of pace and time collected on your $400 Garmin watch, submit a customer support ticket and refer them to this thread.


    Again Strava users - unless you have marked your Run as a RACE, the MILE SPLIT PACES ARE INCORRECT! Repeating the same runs, there is no way to compare your pace as it has been altered by Strava. For those of us running beyond 10-20 miles and on trail hills, the Strava MOVING PACE ALGORITHM alters your actual pace - as it does any time you stop or slow down for any reason. Run a marathon, you don't get credit for for sitting on the side of the road at a drinking fountain - so why does Strava make your pace faster in your training runs???


  • It is all very disappointing, I have been setting any workout that has this incorrectly altered moving pace to race as a workaround.  But I shouldn't need to.

    It really should be just the device or app that pauses activities, that is what the pause button on the watch/app is for.  Not the website, or at least be an option to turn it on/off.

  • As a software engineer, it is a poor design strategy (simply wrong) to overload data fields, as Strava is doing with the use of the field for the "Pace" column under Splits (using the label "Pace" while populating it will data from either "Moving Pace" when the event is categorized as a non-Race, or populating it with data from "Pace" (the real/actual one) when the event is categorized as Race.) and with the "Moving Time" field in the top right of the web page labeling it "Moving Time" but populating it with different data based on if you had clicked the "Lap" or "Start/Stop" button on your device; if those buttons were not pressed, the data of Strava's Moving Time algorithm is used, if you do lap or auto-lap on your device then "Time" data is used, effectively making the label "Moving Time" obsolete and simply wrong (its not the Moving Time).


    So to re-cap: Strava - you use the "Moving Pace" DATA for the "Pace" FIELD, and use the "Time" DATA for the "Moving Time" FIELD. Wrong and bizarre. 


    The simple answer Strava is to NOT overload your field with different types of data. Data is data. Call it what it is. Label it correctly. In this case, to make everyone happen, don't overload fields, just include all the data. Why hide and change data and label it incorrectly?


    Simply do what Garmin does, include all 3 types of data/fields; Pace, Moving Pace and Average Pace. Time, Moving Time and Elapsed Time. Stop changing data of fields based on its categorization! Just label it what it is! Log into your account on to see how they include all data and do not overload fields.


    So everyone is clear on terminology, please refer to the proper definitions of pace and time supplied by Garmin:


    Quite simply, Strava is not displaying this basic data of pace and time correctly and confusing their paying customers as well as making them think they are running faster than they really are.




  • I use a Suunto Ambit 2S; as far as I could tell, there is no moving field in the .gpx file submitted (I upload my runs manually).

    I'm assuming, in my case, that Strava is trying to estimate the time I'm not moving directly from the GPS data. If that is the case, this is not working properly. 

    I have a feeling that if Strava is parsing the data and finds two locations that are very close from the GPS data, it guesses you didn't move. Problem is, it could also be that the GPS polling failed at that particular moment. Other sites have smoothing functions for that; Strava doesn't. If I look at my pace on Strava, it oscillates wildly from 4:00 to 6:00 per km within few seconds. That seems to tell me that Strava is looking at each individual points of data, rather than averaging data over a few points.

    It seems like all sites have a failing of some sorts. This is Strava's.

  • I also submitted a ticket - explaining that they are probably classifying GPS loss as non moving data. To be followed.

  • Was wondering why when my watch said I ran a 7:20, strava would say 7:40, I think I will use garmin connect for split data from now on.  Sometimes strava says you are faster and sometimes slower than the watch, which is useless.  Don't know if this was recent as with my 405cx, it seemed to line up with the watch but not on my fenix.  Overall distance is usually off a bit too.  I tried changing them to race and that didn't help either, still incorrect data.  I too am a software engineer and it wouldn't be hard to just show both moving and regular pace splits.  At least elevation is accurate.

  • I can confirm that what Strava displays is just simply wrong (I agree with the tech theory just above about the GPS points). I can confirm this because when I go for a run I never ever stop till the end of my run, and Strava always shows my "moving" pace as faster than I actually ran. I never stop because if I get to a road junction I will either run on the road and annoy the cars, or if the probability of getting run-over or dying is too high I will go round the corner instead and cross the road when its clear and then double back on myself.

    Strava - Please fix this... I'm so desperate to improve my PBs, sometimes I look back on my runs and actually believe the lies its telling me... I will of course get a nasty shock next time I actually do a race.

  • The default setting for running should be ACTUAL pace. I think defaulting to moving pace for cycling is sensible and safe to avoid encouraging bad behaviour at lights etc. Plus it means you can take the breaks you take over long rides without remembering to pause the Garmin. But for runners it is totally wrong.  This needs a fix. I came to Strava from Runkeeper because I cycle and run and would prefer to use a single app. Personally I will be looking elsewhere if a solution is not coming. 

  • I'm sick of asking Strava to correct my data. What is wrong with them? They clearly have something wrong with their algorithm. I'm a runner, when I run I simply what the elapsed time and splits, it's not difficult. OK, I can change to 'race' and it labels as elapsed time on the overview, but everyone else, facebook etc, still sees the incorrect moving time. I've just done a 5k race in which, according to Strava I must have had a complete blackout and sat down for a nearly a whole minute.
  • Thank you for sharing your feedback about our run analysis and calculations. We truly do appreciate your input, and I've already had a few conversations with our development team regarding this topic. 

    Unfortunately, similar to Travis's response in November, we don't have plans to modify how we display and analyze time for Strava runs. Of course, this is never set in stone, and seeing how this thread continues to gain support we may reconsider in the future. What we do hope to accomplish is to make the labeling of our Time fields more clear and provide more accessible glossaries and definitions for some of our data fields to help with any confusion. Documentation of this information is very important to us too. 

    If you have any specific questions about why we choose to analyze run data in this way, please post that here. I'd be happy to pass along a bit more about our design process around run time. 

    To help clear up any confusion, here are some notes I've worked on with our development team:

    - Runs tagged as a Race will default to Total Elapsed Time for all calculations; average pace, splits, total time, analysis charts, pace analysis, etc. Hopefully this is pretty straightforward and does not provide any data issues for those of you who wish to view the total time data. 

    - Runs tagged otherwise (Run, Long Run, Workout) will default to either Timer Time or Moving Time depending on what is available. There is no explicit labeling between the two, but based on the below information you should know which time analysis Strava is choosing:

    • Timer time represents moving time as calculated by the manual use of the stop/start button during recording whenever you are resting, or the pause button from the Strava mobile app. This also means that any auto-pause features are turned off. However, the only way Strava can read your timer data is if you upload from the Strava mobile app or via the native .FIT file from your GPS device (Garmin for example). GPX and TCX file formats do not contain timer time data. Strava will default to the time calculation if available. 
    • If you do not fall into the above bucket, Strava will calculate moving time based on GPS data. To note, if you find your Moving time splits confusing, remember that GPS data is not 100% accurate and can occasionally record short amounts of time that may appear as resting to the Strava algorithm. The support team has some behind-the-scenes analysis tools for this, so if you have a question about your GPS-calculated moving time please submit a direct support ticket. 

    Thanks, and hope this is helpful! 

  • Please listen to the comments of your users and make the changes requested.

  • Thanks Shawn, for adding your feedback here!

  • Adding one more in support of making pace based on "total time" instead of "moving time" the default. Or maybe having it that way for something other than "race". At the very least, can you bring back the "pace vs. time" display (like how you can still get in rides) instead of only the "pace vs. distance" display? It makes intervals or track runs not make any sense if I can't view it with time as the x axis.

  • I would prefer Strava to use whatever was used on the device recording the activity so if I tell my Garmin to not use auto pause, Strava should follow this. The workaround of labelling an activity a race so elapsed time is used is a method to use in the meantime but my major problem with this is the web based page of Strava now shows my correct race time but the mobile app still shows moving time and is displaying to my followers an inaccurate time. Please, please at least make all the versions of your product the same. Thanks
  • Hi Neil - we're not aware of this problem: If a run is tagged "Race" the same time data should appear on Web and Mobile. Do you have the most updated version of the App? Can you confirm that you're seeing this problem? Thanks

  • Hi Elle. I have version 4.0.1(1631) showing on my iphone. The activity in question is the one on Saturday 5th April and I tagged it as a race on the web version and this is showing on my iphone app but still it it is moving pace being shown on the app vs elapsed time online.

  • I don't think it's Strava's responsibility to be adding in functionality to cater for everyone's individual devices, or to copy Garmin's nomenclature with regards to Time/Elapsed Time/Moving Time/Timer time etc etc etc.

    What is their responsibility to do is to present data in a way that is both accurate and consistent between activities and the current system fails in both regards. With regards to accuracy, the current widespread use of 'Moving Pace' is woefully inaccurate as Guillaume explained nice and succinctly above; this is particularly evident in lap splits and basically makes them completely useless. With regards to consistency between activities, whilst the algorithm 'Moving Time' used to process sets of data may be consistent, the data being fed to them is not; the use of different devices, quality of GPS signal, amount of time spent in poor signal areas (e.g. under tree cover) all have a drastic effect on how much of your run is calculated as 'Moving Time' and thus on your pace.

    The use of 'Moving Pace' is ideally suited to workouts such as intervals, NOT to every single activity, where actual pace is far more appropriate. It should be the exception not the default and thus, in my opinion, moving pace should be applied when you tag an activity as a workout and actual pace used as the default for every other run type.

  • Is this a joke? Uploaded Garmin foreunner 110 from 5k race today. True time, i.e. elapsed time, was 19:31, moving time 18:46 (moving time is shown when sharing, even when labelled race). Unless I had a complete black-out, I don't think I stopped. Totally agree with last comment, moving pace should not be the default, particularly when it is always calculated woefully incorrect.....I DONT CARE ABOUT MOVING TIME WHEN I'M RACING......although a time of 18:46 would be nice!

  • Well given Elle's recent response, I think it's quite clear that as things stand the situation is not going to change.

    I think it's disingenuous of Strava to process data this way by default and it's only when I started to analyse the large discrepencies in my lap times between my Garmin and here that it all finally came to my attention. I would encourage everyone who has friends or clubmates that aren't aware of this process to enlighten them and encourage them to post their feelings on this thread. It's only when a support thread like this reaches several hundred responses that Strava will actually take any sort of notice.

    For the most part I think Strava works brilliantly, but this is such a catastrophic misappropriation of data analytics that it almost makes the whole run function unusable. For the meantime, I'm just going to be tagging the majority of my runs as races (even though they're not) just to get some comprehensible data out of the site.

  • Unlike some of the other posters, I have no problem with moving time being used as a basis for calculating paces etc.  You can always flag a run as a race to get round this  Unfortunately, I think the calculation that Stava uses for moving time is flawed. 

    An example to illustrate.

    Roy who I follow did this run recently:-  He currently has it flagged as a race and it shows an average pace of 18:17 mins per mile.  This is because he is returning from an injury and had to walk parts of the course.  If he changes the the run so that it is not a race,  It now shows 7:44 a mile and gives him a world record beating pace of 40 seconds for 400m!!


    The reason for this (I believe) is twofold. 

    1) Walking should still be classed as moving time so the threshold for moving is set too high in the Strava calculation.  I have a Garmin Forerunner and I set auto pause to kick in whenever I drop below 20 minute mile pace as this seems sufficient to record stops correctly.

    2)   If walking is not included in the moving time then it should not be included in the moving distance. Taking the time out without taking out the distance results in sections being done in 0 seconds which results in overall world record pace calculations!


    As I have not seen Strava's calculation, this is pure guesswork on my part but it seems like the most likely reason for all the discrepancies.


    It would nice if Strava could have another look at the calculation and see if there is indeed a bug here. 

    Other than this, keep up the good work, I am really enjoying using this site and may upgrade to Premium in the future.

  • I believe Strava were on the brink of removing the 'Best Estimated Efforts' (such as the 400m WR you mention here) altogether. They're inherently inaccurate because of the (sometimes poor) quality of GPS data being fed into Strava and they highlight in a very obvious way the limitations of such analysis based on dodgy raw data. That is fair enough. I think everyone takes the 'Best Estimated Efforts' with a pinch of salt, especially so for the shorter distances.

    But what your case highlights so well is the absolutely woeful manner in which Strava calculates moving pace. I very much doubt there is a bug in their formula. Again it's a complex situation having to deal with with variable types and quality of data being fed to it, that come from a variety of scenarios, all of which have to be accounted for. This is why it is so unsuitable for routine analysis of run data, it is neither accurate nor consistent.

  • Quote: You can always flag a run as a race to get round this.

    I do not think flagging all my workouts as races is an ideal solution. I also do not believe that data should be manipulated without being optional.

  • I am now flagging all my runs as races so I can see the actual pace/time. And I agree this is not ideal. So I'm yet another user who supports a change to using Total Elapsed Time.

  • Attached is time shared on Facebook for a race at Parkrun, 18:39 tagged as race. My actual time was 19:41 (elapsed time). Why would I want to lie ?

댓글을 남기려면 로그인하세요.

원하는 것을 찾지 못하셨나요?

새 게시물