Sounds like a routing issue from the provider. There is this ridiculous practice in network service called "Least-Cost Routing", where service providers have algorithms constantly scanning for the lowest cost routes for traffic and, at set intervals, will automatically switch routing through the lowest cost switches and lines from their partners (and competition where allowed). When they do this, it creates two VERY frustrating problems: 1. Pings, packets, line quality and everything else seem to suddenly take a dump. 2. When techs go to troubleshoot or open tickets, the routing has likely already changed again and the problem seems to no longer exist.
So, unless you can get someone who both knows how and is allowed to look at the logs of where all the different points that traffic was routed through at the time of the problem, you are never going to be able to find it. And, even if you do find it (which becomes almost impossible when you route through another carrier who also may have been using Least-Cost Routing), you can never get a service provider to get a carrier to agree to stop using LCR... or to get all their partners to agree to the same.
In the end, it comes down to the fact that none of us ever have a direct connection to the server... and it changes all the time.
I just saw the result of a very detailed trace-route here at work last week where our net-ops guys were trying to solve this same kind of problem. We had traffic that was being called from a server in downtown St. Louis by an office in Joplin Mo. (this is only like a 150 mile trip) that ended up going first to Dallas, then was sent to Salt Lake City, then was sent to Chicago, then went to Kansas City... before finally going to Joplin. And the traffic was handed off to 5 different carriers during that trip.