I want to provide a quick update on this (ongoing?) issue…
I’ve made a number of changes in the last week, last night, and today that I hope will go far in working towards a full fix.
The system is much more careful about queuing up map data jobs if there’s already something running/queued. I think this will help avoid some file clobbering that may have been happening, but I have some slight concern for the situation where someone uploads multiple activities at once (or very fast) - I think this could result in the LifeMap being updated for the first activity but for subsequent activities. I don’t think it’s very common for this to happen, though.
I’ve had to do some 
operating system tweaks to account for the fact that there are hundreds of these map data files being served. I think my recent changes will help avoid some OS-level errors that could have been happening.
I increased the size of the map data server, after noticing some out-of-memory errors hidden away in logs. This was just done last night, but I’ve already noticed a significant difference in memory/swap usage.
Related to that, I noticed that my code was not closing the database files after the query was complete. 
It’s doing that now. 
Finally, I’ve switched the underlying package I was using to work with these database files to one that claims to be 10x faster. 
This is one of the most important issues going on in CityStrides right now, and I’m hopeful that my recent work will help to resolve it. 
I’m really bummed that this huge improvement to the LifeMap has been overshadowed by all the breaking maps. Thanks for your patience, everyone!
Let’s continue this thread as-is … Please let me know if the LifeMap breaks for you again.