A monitoring blind spot
Your monitoring covers everything from the user's click to the kernel… except maybe the thousands of kilometers of network in between?
Here is what most modern monitoring stacks look like:
- The front-end UI is instrumented.
- Every (micro-)service composing the backend is instrumented.
- All this instrumentation and logs are sent to some central collector(s) in the cloud.
- Some dashboards and alerts are computed from that trove of instrumentation data and the VM statistics made available by the cloud provider.
On paper, everything is covered: from the user’s click down to the deepest kernel wait queue (thanks to eBPF) and back up to global vCPU and network-interface utilization (give or take Joe’s old laptop, still running a vital service under his desk two years after he quit).
There is just one little oversight though: your users are not sitting inside the data center. Between them and your servers lie thousands of kilometers of complex infrastructure, involving many different players; and this part is oftentimes overlooked.
Most front-end instrumentation frameworks report connection issues, but they can see only what the browser will report, namely L7 connectivity.
The most astute DevOps would have a makeshift network monitoring setup based on iperf, ping and mtr measuring various latency/reachability metrics from a few places, ideally archived within reach of the alerting system, but more often than not your team will stare at the internal metrics until getting confident that “it must be some network glitch, again”.
Treating the outside network as a black box just because you can not directly act on it is not optimal. Sure, you are not going to fix a submarine cable cut or a flapping route in between two AS you didn’t even know existed.
But with better visibility on the outside world, you may be able to:
- Save some time (and some tokens) diagnosing the issue;
- Know who is in charge;
- In some cases, route around the issue;
- Silence other dependent alerts;
- Measure how fast and reliable each link really is;
- See where your traffic is really flowing, and which external actors your service implicitly depends on.
Cloudy is a service that tries to fill the gap between your clients and the infrastructure you control, to eliminate that last blind spot in your monitoring.
What makes Cloudy better than iperf + ping + mtr?
Cloudy-with-a-chance-of-latency is easier to deploy and manage. No service to manage, no data to store, everything is taken care of. You just deploy a docker image anywhere, and it starts monitoring. You can then control the whole fleet from the UI, or just point your AI agent to Cloudy’s MCP server, and you are done.
Cloudy is also more flexible: It is designed as a general purpose point-to-point continuous network monitoring tool. The network probes are flexible and can execute all kind of network tests such as those performed by iperf, ping or mtr and others. Beside the computed metrics, all generated traffic is available for further inspection: if you want to see the actual packets, you can.
Cloudy is also careful with resources: The probes generated traffic is sparse to avoid incurring high egress costs. The probe image is small and can be easily embedded in the smallest VPS or even alongside any box where you already run anything.
Cloudy remembers each individual router on the way and evaluates hop-by-hop metrics. It won’t just tell you: the connection from clients in Germany to the datacenter in Ohio is getting unreliable; given enough data it will pinpoint the actual guilty router and/or AS interconnection etc.
Cloudy shares public information: Performance of public infrastructure is shared: BGP events and external routers performance measurements are shared between users, in order to get a more accurate picture of the situation.
No resources to onboard yet another product?
Not every company has a team of hardcore network administrators with experience in international routing, and deploying another tool that nobody will look at or know how to use sounds like adding even more noise to an already noisy signal.
SOTA LLMs, in contrast, are very familiar with network infrastructure.
They already know the big players, the global topology, the routing protocols, what you can (and cannot) learn from a traceroute, the conventions regarding core routers naming, where they are located and who is in charge, etc. They are surprisingly good at taking advantage of that data.
So in reality your team doesn’t have to onboard anything or read a single manual page.
Cloudy-with-a-chance-of-latency has an agentic interface (namely, an MCP server) that Claude, ChatGPT or DeepSeek are very able to use out of the box, and that’s designed to give the LLMs the synthetic information they need rather than flooding the context with loads of low level measurements.
Give them the permission to deploy small VPS and a traffic budget, and they should be able to build the monitoring network that they will need to help monitor your services.
If you don’t take it from me, take it from them!