I don’t think that GlassWire should have ISP monitoring of network latency … full-stop or as near to it as I can think of. 
Definition
To be precise we should be talking about “network latency” including e.g. misconfigured network adapters. This doesn’t address other latency issues such as a misconfigured or defective software or devices.
Priority
I don’t think that this is a worthwhile feature to pursue when much more useful features are yet to be implemented in GlassWire. I’m specifically thinking of the many bandwidth management features that have been requested.
A list of more useful features would be long and would also include: the ability to export all GlassWire statistics, user specified time periods, etc.
ISP service levels
Why measure network latency when most ISP’s sell broadband connections based on bandwidth rather than latency. And even on bandwidth it is nominal not actual bandwidth with limited or no service guarantees even on connection uptime because ISP service tends to be on a best effort basis.
I’ve not seen a user who gets a service level for latency except for commercial users who pay a premium or pay a lot more in total for that SLA (Service Level Agreement). Until latency service levels are more common then I wouldn’t bother with them.
As for getting action from an ISP, a graph doesn’t add anything that is better than the time data (in milliseconds). It is quite possible for ISPs to have misconfigured their routes. In that case, a basic ping/traceroute utility is sufficient to identify the issue and get action on the poor result. In the event that you identify your ISP’s inadequate interconnection arrangements then more stats won’t usually influence such commercial decisions.
GlassWire scope
There are several contributors to latency issues on user devices that are not network related. Even if you only look at network latency, it doesn’t have much in common with GlassWire’s existing feature set of network security, local device monitoring and firewall management. This is unlike the requested bandwidth features which do overlap with GlassWire’s existing features and statistics.
The request might look easy do, and it probably is, but this is scope creep for little real-world benefit.
Edit: Actually I have thought of a reason why you might want to measure network latency. If GlassWire decided to get into traffic management. But this is another idea best avoided. The downside risk of botched configuration is much greater than any performance benefit.
Network diagnostics
If it is going to be done, then it should probably be done in a separate network diagnostic program because most users will never need it. And if they do, then there are utilities that already do this stuff.
Also, I don’t think that it is sufficient to produce network latency statistics because the difficult part is always the diagnostics. If you don’t provide a diagnostic feature then people will be asking for it because otherwise why would GlassWire include such descriptive statistics?
If GlassWire is seen to need it then latency statistics should include awareness of geographic distribution. If the “high” latency is simply due to long distances then it is not a problem that needs further investigation. GlassWire could estimate this which would be useful (it does relate to the planned whois features) but again this is not needed very often.
“User error”, for example
Many users desire low network latency but persist in using WiFi when they should be cabled for a more consistent response time. A good first step when looking at network issues is to stop using WiFi so that WiFi problems don’t complicate the issues.
Have a look at this article on cabled versus wireless on the League of Legends game:
http://na.leagueoflegends.com/en/page/ethernet-vs-wifi-ping-packets-playing-better
See the graph for Percent of Games Played by Connection Type by Tier
