What to use instead
For the question traceroute usually answers -- is this host reachable and how far away is it -- the Ping Tester measures TCP handshake time and needs no special privileges.
For the question of who carries the traffic, the WHOIS Lookup reports the autonomous system number and network operator for an address, which tells you whose network a host sits on without needing to see every hop.
Running a real traceroute yourself
On your own machine you already have the privileges. On macOS or Linux run `traceroute example.com`, or `mtr example.com` for a continuously updating view that is far more useful for spotting intermittent problems. On Windows the command is `tracert example.com`.
Read the output for the hop where latency jumps and stays high, rather than any single slow hop. Routers deprioritise generating ICMP replies for themselves, so one hop showing high latency while later hops are fast is normal and means nothing.
Restoring it on your own infrastructure
Running this application on a virtual machine with root access rather than a container platform would make a real traceroute possible. That is a genuine trade-off: containers are easier to deploy and cheaper to run, and traceroute is the main thing you give up.
What a traceroute does not prove
A traceroute shows one direction only. Your packets take the path it prints; the replies come back by whatever route the far end chooses, and the two are frequently different. When a trace looks fine outbound but the connection is still slow, an asymmetric return path is one of the common explanations, and nothing you run from your own machine will show it to you.
The last hop that answers is also not automatically the faulty one. Traces routinely stop at a firewall that is deliberately silent while traffic passes straight through it, so a run that ends in asterisks two hops short of the destination often means the destination is reachable and simply quiet.
This matters when you report a problem. A single trace is weak evidence: it captures one path at one moment, from one place. Run it several times, run it from a second network if you can, and send the timestamps along with the output. A provider can act on a pattern across several runs; they can rarely do anything with one snapshot.
Frequently asked questions
Will traceroute be added later?
Only if the tool moves to a host that grants raw-socket access. On container platforms it is not a matter of writing more code -- the capability is withheld by the platform.
My trace stops before the destination. Is the host down?
Usually not. Check reachability separately with the Ping Tester: if the host completes a TCP handshake, it is up and something along the path is simply declining to answer expired packets.
Does traceroute show the path my traffic takes back?
No. It maps the outbound path only. Return traffic can take a different route entirely, which is why a clean-looking trace does not rule out a problem in the other direction.
Why does my own traceroute show stars for some hops?
Many routers are configured not to reply to expired packets, or to rate-limit those replies heavily. Asterisks usually mean a router chose not to answer, not that traffic stopped there.
Is traceroute reliable for measuring latency?
For the destination, yes. For intermediate hops, no. Routers handle forwarding in hardware but generate ICMP replies in software at low priority, so intermediate hop times often look worse than the path actually is.