I just got the same issue with Gothenburg: https://www.streetferret.com/sf/allstreets?c=935611
I've made a bunch of updates to OSM and then used the Report a problem and clicked missing streets to update the city, but it is all blank. I've clicked missing streets again today, but still blank.
I did the same with another city "Skövde" and now that one is blank as well: https://www.streetferret.com/sf/allstreets?c=935485

I also see a lot of runs with "0% Processed". Even older runs.

Sorry, Stockholm and Solna are still missing. Go to Explore - All Cities, and search fo Stockholm, you only find the one in Wisconsin, not Sweden... 

And look at my activity https://www.streetferret.com/sf/run?a=5029840139 . When it says View activity on Streetferret map, it lists Lidingö and Stockholm. If I choose Lidingö I see all streets fine, if I choose Stockholm it's just an empty map
And for activity https://www.streetferret.com/sf/run?a=5047855063 the same thing, for Huvudsta it work fine, but for Solna, it's a blank map

Great, now they are back,  thanks!

When you use the "report problem" link to force-load a city, that forcibly deletes the city's street data and re-loads it from scratch.  So there is a period of time when that city's data will be offline while that's happening.  This is the same processing that happens if the system detects that a city's boundary has changed. Normally this only takes a few minutes, maybe 10s of minutes at worst case for big cities like Sydney or Houston.

During normal updates, if the city's boundary hasn't changed during a routine city update, it will only apply the changes to the streets in that city that have actually changed, which is a faster update.  However, this update will only occur when that city comes up next on the up.

If the city update service is offline because I'm troubleshooting a problem, then the city can get stuck in an offline state until it comes back up.

Everything is still a bit more fragile than I would like it to be, and in particular I'm trying to chase down an issue with recovering from database disconnects which happens over an hours-to-days timeframe.  The goal is to make everything perfectly turnkey and with the database updates being current to less than a week.  I've had it at < 3 days at one point so in theory this quality of service is achievable on a general basis.