Four Ways to Watch a Network
The columns are categories, not vendors. "Ad-hoc scripts" is ping, traceroute and curl in cron. "Host monitoring" is the classic check-based systems built around service and host state. "SaaS uptime checkers" are hosted services that poll your public endpoints from their locations. Every row describes what each approach does on its own, without add-ons.
| Capability | TRCR | Ad-hoc scripts | Host monitoring | SaaS uptime checkers |
|---|---|---|---|---|
| What it measures | The network path and the service: RTT, jitter, loss, hop-by-hop route, DNS answers, HTTP phase timings, certificate chains, BGP sessions, TCP throughput | Whatever each script prints; usually reachability and a single latency number | Host and service state: up or down, thresholds on a check's output | Reachability and response time of public endpoints from the provider's locations |
| Probe types | 14 built in: ping, batch ping, TCP, traceroute, liveness sweep, NTP, path MTU, HTTP/HTTPS, SSL expiry (with chain inspection), DNS, DNS propagation, native throughput, SNMP, BGP; full list on the probes page | One per script you write and maintain | Broad plugin catalogues, mostly service checks; path and throughput probes are add-ons | HTTP, ping, TCP port, DNS; path analysis is rare |
| Path visibility | Continuous traceroute with automatic route and AS-path change detection; old paths kept for comparison | A traceroute in a log file, compared by hand | Not a core feature | Occasionally offered on failure, from the provider's vantage point |
| Vantage points | Your own agents, anywhere you can run a binary: data centres, branches, cloud regions, customer sites. Agents probe each other automatically in a full mesh | Wherever you install the cron job | The monitoring server, plus agents you deploy and configure one by one | The provider's points of presence; your internal network is invisible to them |
| Configuration | One YAML file on the master; the master pushes configuration to every agent | Per host, per script | Host, service and check definitions per target, often thousands of lines | Web UI, one check at a time, or an API |
| Where the data lives | Your Elasticsearch, InfluxDB, PostgreSQL or Prometheus, any combination at once. Structured records, not log lines | Log files and whatever you parse them into | The monitoring system's own store; export varies | The provider's platform; retention is a plan feature |
| Dashboards | Your Grafana or Kibana. The dashboards used by the live demo are published at github.com/trcrdev | None unless you build them | Built in, focused on state and alerts | Built in, hosted |
| Privileges | Runs as an unprivileged user with Linux capabilities for raw sockets; ships hardened systemd units | Usually root, so that ping and traceroute work | Varies by plugin | Not applicable; nothing runs on your hosts |
| Pricing model | Free tier forever (5 agents, 5 monitors per probe type, every bundle). Paid bundles are flat annual prices per capacity tier, not per check or per user | Free, paid for in engineering time | Open source or per-host licensing | Per check, per location or per user, monthly |
| Best fit | ISPs, MSPs, enterprises with WANs, and platform teams that need to know how the network between their sites is behaving | One-off diagnosis | Fleet health and alerting on hosts and services you already run | Public website uptime as seen by the outside world |
Which one should you use?
Often more than one. TRCR does not replace host monitoring or an outside-in uptime checker; it fills the gap between them.
Keep your host monitoring if you have it
Check-based systems are good at what they were built for: is this host up, is this service answering, is this disk full. TRCR answers a different question — what is the network doing between here and there, and did the path just change — and writes its results to the same databases your other tooling already uses.
Keep an outside-in checker for your public site
A hosted checker sees your website the way a stranger does, from networks you do not control. That is useful and TRCR does not try to be it. TRCR's agents sit inside your network and at your sites, where a hosted service cannot reach.
Replace the scripts
The cron jobs running ping, traceroute and curl are what TRCR was written to retire. One daemon, one configuration file, every probe type, structured output, and a mesh of agents that configure themselves from the master.
Not the TRCR token
Searches for TRCR also return a cryptocurrency that uses the same four letters as its ticker. That project has no connection to this software. TRCR at trcr.dev is a network monitoring daemon sold as software licences; nothing here is a token, coin or carbon credit.
See It Before You Install It
Live Data From a Running Mesh
The demo is a public Grafana fed by a real TRCR master and its agents.
No account, no sign-up. Then start free with 5 agents of your own.