I’ve set up a Status page to (hopefully) make it easier for everyone to see what kind of load the background system has & where things stand with Strava API usage.
I already have some changes that haven’t been released yet, but please let me know if something doesn’t make sense or if there’s different/more information you’d like to be able to see.
It’s also linked in the main navigation as Status.
Update: The enormous Strava queue, due to their low API limits, has caused this page to be unusable. I have had to remove a lot of the stats from this page in order to make it usable. Hopefully I’ll be able to re-add those in the future.
Since members are all over the globe, maybe you could find out and write down at what time the number of daily API calls for Strava is reseted.
First day with the Status page and first peculiar situation: the activity processing delay is supposed to be less than a minute in CityStrides and there should be no problem with Strava if I understand correctly but I have been waiting for 2 hours.
It is not critical because I don’t want to run in the same neighborhood tomorrow, but I am always curious to check if I have caught all the nodes I had planned.
Otherwise, I am sorry (because of the API limit) that I currently do 3 activities/day: 1km run to the station, core activity, 1km run back home from the station. The shorter runs are not too useful in Citystrides (with the current set of statistics) since I don’t run any new street/node but they are imported as well.
I’ll have a release out soon™ that will more accurately change “reset daily” to “resets at midnight UTC”.
Yeah, the difference/relation between “Activity Processing Delay” and the Strava API limits is confusing.
The Strava API limit is a limit that entirely blocks the activity sync process from starting. If CityStrides reaches the limit in a 15min period, no further activity sync/import occurs at all - so, in this scenario, the Activity Processing Delay is a moot point because we can’t even get new activities into CityStrides to process.
The Activity Processing Delay is whatever delay might exist for processing an activity after its sync has been started. This delay is probably visible in that the activity will exist in CityStrides but it will have 0 completed/progressed streets until the processing is complete.
Maybe I should included these paragraphs to the right of the boxes, to help everyone understand what the numbers mean. Was this description useful - do you understand what the different sections mean now? (I don’t want to update the page with more confusing words )
Maybe I’ll change
This is the delay for an activity to be fully processed in CityStrides.
to
This is the delay for a new activity to display its progressed/completed streets.
Yes, I now have the confirmation that the delay starts once the activity has been transferred to CityStrides… but if it is not the case, and the syncing does not happen although none of the 2 Strava API limits has been reached, I still don’t know what to think (I can wait, no worry, but since you ask for feedback, I tell you what I see).
Up until last night, I wasn’t handling Strava limits very well. This would sometimes result in activities being “missed”.
The current code shouldn’t allow this to happen - it should instead keep the sync ‘scheduled’ (Strava activities scheduled for import in the status page) either 15+minutes or 1+day in the future, depending on which limit is reached.
So this scenario of an activity not being in CityStrides and none of the Strava limits being reached shouldn’t exist, going forward.
This does bring up an interesting idea of displaying to people how many of their activities are present in that ‘scheduled’ set. I think I might have enough data to do that, potentially even with a link back to the Strava page for any activities.
We’ve reached the daily limit (a release is on the way that explains how some queries are “saved” for each limit pool). It resets at midnight UTC, which is pretty soon.
Interesting… how can I tell that the daily limit was reached from looking at the Status screen?
The Activity Processing Delay would indicate a fairly quick process (perhaps this is how long it takes after the activity is scraped from Strava?)… and the Strava queue looks like there’s lots of API calls remaining (not that I really know what that means).
IMO if Strava is the first step, maybe it should be above the Processing info. Without Strava, there’s nothing to process.
I think Jeremy makes a good point regarding the order, it would be more intuitive to have the process in sequence. Maybe it could be presented as a table, with the info for Runkeeper and MapMyRun also included (even if it seems that Strava is the only one that is actually a constraint)? That would make things bit clearer and give the Status page relevance for non-Strava users as well
I don’t know (and can’t know) what percentage is Garmin → Strava → CityStrides
I did start a Garmin API interface, but haven’t finished yet. Their approach is wildly different from all other trackers (because they are device based and therefore way less real-time). It’s quite difficult.
I wonder how the Strava → Garmin pipeline works. Because it’s pretty much instantaneous. Maybe Garmin is pushing to Strava? I see it’s an authorized Application in Garmin Connect.
The enormous Strava queue, due to their low API limits, has caused this page to be unusable. I have had to remove a lot of the stats from this page in order to make it usable. Hopefully I’ll be able to re-add those in the future.
I’ll have a release out soon™ that will more accurately change “reset daily” to “resets at midnight UTC”.
Maybe I should included these paragraphs to the right of the boxes, to help everyone understand what the numbers mean. Was this description useful - do you understand what the different sections mean now? (I don’t want to update the page with more confusing words 
)
not every user is a Strava user
the latest release of the status page includes some changes based on all this feedback