Roman, I explored that case with big amount of files in a shared folder a bit further. Here are some more inputs, that may be of interest: Removing all user files from that big shared folder didn't solve the problem immediately - although btsync was showing 0 files in the folder and there were no peers to sync this folder with, btsync still consumed quite some resources (mainly RAM) and WebUI was still very unresponsive. As next, I wanted to completely remove the folder from sharing, via WebUI, and it didn't work - after clicking OK in the delete confirmation popup nothing happened. I looked then at the AJAX communication of the WebUI, and discovered something nasty: JS sends 'getsyncfolders' request every second... no matter what was the result of the previously sent requests! Then the explanation for not working folder remove became evident: As server was responding very slowly, it took minutes until the folders info initially updated and the "remove" button appeared. All subsequent update requests were processed very slowly too. Since I was not staring at the screen all the time to react immediately once remove button appeared, every extra minute of waiting added another 60 'getsyncfolders' requests to the queue less few that were processed. Then, as remove request was finally posted, there were already so many 'getsyncfolders' requests pending upfront, that the processing never reached this remove request, before browser marked it as failed by timeout. I additionally confirmed this the root cause by clicking remove as soon as possible next time and watching the network activity - the folder was successfully removed as the processing reached the remove request. btsync immediately resumed normal operation. Proposed solution: count pending 'getsyncfolders' requests in JS, and skip/delay further requests if the counter is above a certain limit. Actually, for update period of 1s I'd say just one pending request is enough, max. two.