About the Status Page

CityStrides has a status page. Hopefully this will help you make some sense of it!

Section 1: Strava Sync
Strava limits how many times Citystrides can access its data by the 1/4 hour and by the day. This section tells you the current information and gives you a sense if there might be a delay in your Strava Activity getting brought into CS. If your account doesn’t seem to be updating, but there are “activities scheduled for import” that is probably the reason.

Those who support the site get priority in Strava import of new activities.

Strave queue priority:

  1. Subscriber new activities
  2. Regular new activities
  3. Subscriber historic activities
  4. Regular historic activities

Section 2: MapMyFitness Sync
Similar situation as to Strava, but a lot fewer Striders use it to get their activities into CS, so it is usually in better shape with regards to the limits.

Section 3: Runkeeper Sync
Unlike Strava and MapMyFitness, every Runkeeper sync is a full-account sync, so this section is set up to show how many accounts are currently scheduled for import from Runkeeper

Section 4: Activity Processing Delay
Once your activity is synchronized with your data source (Strava, MapMyFitness, etc) the Citystrides server needs to take that data and calculate the progress you achieved during that activity and show it on your account. Site supporters get improved priority when it comes to this step in the process.

While waiting for this processing to complete, you may experience a situation where an activity shows on your profile, but either shows no completed/progresses streets or shows progressed streets but no completed streets. In most cases, more time is all that is required for this to continue to process before it is done.

Section 4: LifeMap Generation Display
Did you know supporters of the site get an advanced LifeMap? Benefits include faster loading, map filtering, the “Node Hunter” function, activity track identification and more. This section indicates the delay in the Citystrides servers initiating an update of that LifeMap once an activity has been synchronized to your account. Actual processing time of this map varies depending on server load and account activity count, so there may be an additional delay between synchronization and the map processing being completed.


What does it mean when the “Quarter-hourly API calls left” is a negative number? I’ve been seeing this lately. Probably becuase I’m looking more. :upside_down_face:

Thanks for the added details @jpbari - but I recommend avoiding screenshots whenever possible. These quickly go out of date.

@ericjrw I’m considering removing this 15min report, because of how absolute trash it is. 600 requests every 15 minutes over 24 hours is 57,600 API calls. So their limit only accounts for half a day :man_facepalming: so I have to self-limit further - down to 300 requests. Some additional requests like logins or me testing things will still work, which can bring the calls left below zero.

1 Like

Why is full-account historic data sync 3? I supported as I like the product + thought it would make the site usable sooner. But at this point it’s not usable and I have no idea when it will be because I have but a few activities imported.

I’d be fine if it took a few days to update after each run as I can make a mental note about which streets are remaining, but I don’t have a starting point without historical sync.

I updated the post.
It’s still third in line, allowing regular new activities to sync in first.

My current take is that everyone (existing/new/supporter/regular) can at least have new activities count towards progress … and all the historical data will eventually also add to progress. I’m basically looking at a nearly saturated connection and trying to find the least worst way to handle it.

1 Like

Thanks for the reply. I hear you re: find the least worst way.

As a new user, my first questions are ‘which streets do I need to run on to get to 100%?’ and ‘What % am I at right now?’.

My understanding is that historical calls return 100 activities per request vs. new activities which are 1 for 1, so wouldn’t historical API calls be a higher bang for your buck?

I may not be a typical user though…not sure if that’s everyone’s first question as a new user or not. Also I may be misunderstanding the historical calls.

It took me a while to understand it better, but this is how I understand it:

First CS has to grab the background information about every activity to figure out what to do with it (metadata). Daily activities use 1 API call to get this background info, historical downloads use 1 API call to get the background for 100 activities.

Once CS has the background info, then it can download the GPS data, and that is 1 API call per activity, no matter whether new or historic.

So, each daily activity download uses 200 API calls per 100 activities and historical activity downloads use 101 API calls per 100 activities.

1 Like