I was a network engineer for a global firm with around 30 remote sites. Sure, the backends(servers) can get busy. But we also found issues similar to whats being reported now. Some users, Canada for example say no issue. They may be using a different set of circuits on the Internet to get to RCU than others. More than likely only the "last mile" of network connections to those server(s) is in common with all. We had that same issue many times . RCU would be the customer of the local network provider, the "last mile". Another vendor, like Verizon for example, may be carrying much broader connections to the net. The local provider would be Verizon's customer. RCU may not have direct contact with Verizon or whomever the broader connector is. RCU would have to be in contact with their local provider and insist that the circuit be troubleshot all the way thru.

As I found out after being involved with that for 12 years, the network is always blamed first, even though more likely than not, the back end servers or databases were the root cause of the performance issues. If the server support folks arent sharp, they will automatically blame the network instead of properly troubleshooting the issue. In this case however, some users report no issues. Unless there are multiple front end servers supporting connections to that back end, and the bottle neck is one or a cluster of front ends, then some part of the circuit to the net is at fault and would not be directly under RCU's control. But it would still be their responsibility to gripe as much as it takes to get a resolution.

When multiple systems are involved in getting data to users, the blame game can really lengthen the time of resolution. Sad but true.