What makes it worse is the lack of transparency. If there were clear, hard limits, people could plan around it. Instead it’s this moving target that makes it impossible to trust for real work.

At some point it stops feeling like a bug and starts feeling like a pricing experiment on users.

Edit: to be clear, A2A does not include payment functions but it has some projects close to it that look like it’s trying to solve the same thing. A2P comes to mind from Google: https://cloud.google.com/blog/products/ai-machine-learning/a...

Traceroute may not be perfect, but the idea that it’s “useless” or fundamentally flawed ignores the tool's actual purpose and its value in controlled network environments or simple troubleshooting scenarios. For instance, traceroute remains effective in diagnosing where an issue shifts from LAN to WAN, as a starting point to eliminate local network problems. In fact, as some commenters pointed out, traceroute often helps ISPs and network engineers by offering visual, actionable clues about where connections are failing or lagging. If you have a network you’re responsible for end-to-end, or you’re troubleshooting with other network teams, traceroute can save time and clarify if there’s an issue within your own network or further upstream.

As for claims that traceroute outputs are too "random" or unreliable to be useful, that’s only the case when people misuse it or fail to understand how it works. No seasoned engineer expects traceroute to provide flawless accuracy, but they know what patterns and data points to look for and how to combine it with other diagnostics. Calling it a "hack" overlooks the simple elegance of leveraging TTL Exceeded responses to map packet paths—a clever solution that’s worked for decades precisely because it provides unique visibility in a non-intrusive way.

The problem isn’t traceroute itself but rather how it’s used and interpreted. Sure, if you’re just firing off traceroute commands without an understanding of what the results mean, you’ll likely draw wrong conclusions. But for those with the knowledge to interpret it properly, it’s a simple, lightweight tool that often provides just enough to kick off troubleshooting.

Instead of writing off traceroute as useless, a more helpful approach would be to recognize its limits, use it within those bounds, and understand that while it won’t solve every networking mystery, it’s still valuable in the right contexts. No diagnostic tool is infallible, and the defeatist attitude of "it’s useless because it’s not perfect" is just unproductive. The goal isn’t to replace traceroute but to use it wisely alongside other tools to get a fuller picture—especially when alternatives aren’t widely implemented or easy to use.