Prepare for Offline Mode fails with error code 504

Using version 1.1.0 of the TroopTrack iPhone App, I’m not able to “Prepare for Offline Mode”

A box comes up with “Fetch Failed: Error Code 504”

Using the developer API, I get the same response from “GET /api/v1/offline?troop_id=XXXX HTTP/1.1” from my computer: (the XXXX is replaced with our actual troop_id)

(Our Troop is very large, so that could contribute to the length of time it takes to generate output from the web server, leading to the timeout).

Just started using TroopTrack (awesome!) I find that with version 1.2.0(2) on iPhone, I’m not able to “Prepare for Offline Mode”

Each time a box comes up with “Fetch Failed: Error Code 504”.

I will follow up with the Developers.


I’m having the same issue. I tried prep for offline mode for the first time to practice for an upcoming campout and got the Fetch Failed Error 504.

Any help/guidance would be appreciated. The offline mode is the primary reason to have the mobile app.


This is still happening… any idea when this might be fixed?

This is still an issue. Is anyone looking at it?

Our mobile app is managed through a third party. Unfortunately, they do not offer a lot of support and have not been as responsive as we would like. At the moment, our hands are tied when it comes to any changes to the TT app.

Sorry! :frowning:

This isn’t a “mobile app” problem, even though that’s where it is seen most.

The problem has to do with the TroopTrack API, specifically the “getV1Offline” API.!/offline/getV1Offline


I am using almost every other API, and this is the only one that times out (all the other APIs are able to return in under a minute).

There is something that isn’t waiting long enough (apparently 1 minute) for the server to return the information.
This used to work for me when I was building up our troop, but once we got everyone (300+) in and going, it stopped working with that error. Each time, the error occurs after 1 minute of wall time.

Sometimes, when TroopTrack is busy, other “user” reports of ours fail to be returned, falling with the same error code, and, each time failing exactly 1 minute of waiting for the server to return data.

I’m guessing there is some server transaction timeout set to 1 minute. Perhaps 2 minutes would be a better timeout?

Thanks for looking into this frustrating issue. The bug takes away what was special about using the mobile App.