Frequently Asked Questions

TRCR is a self-hosted network testing and monitoring daemon. It continuously probes your infrastructure — servers, services, DNS, TLS certificates, routing and network paths — with 14 probe types, and ships structured results to your own PostgreSQL, InfluxDB, Elasticsearch or Prometheus. One master and any number of lightweight agents form a full measurement mesh from a single YAML file, replacing ad-hoc ping, traceroute, curl and bandwidth-test scripts with one system that runs 24/7. TRCR is made by NameVerse, Inc. in Palo Alto, California. It is not a cryptocurrency, token or carbon-credit project, and has no connection to any project that uses the TRCR ticker.

TRCR supports 14 probe types: ICMP ping and batch ping for latency, jitter and packet loss; traceroute with automatic path and AS-path change detection; HTTP/HTTPS with a full request phase breakdown (DNS, TCP, TLS, TTFB, transfer); DNS and multi-resolver DNS propagation; SSL expiry and chain inspection; TCP connect checks; native throughput testing; BGP prefix and origin-AS monitoring with announced and withdrawn prefix tracking; SNMPv3 device, interface and sensor polling; NTP clock offset; path-MTU discovery; and fleet liveness sweeps. The Web bundle holds HTTP, SSL expiry and DNS; Reachability holds ping, batch ping, TCP, traceroute, liveness sweep, NTP and path MTU; Performance holds throughput, DNS propagation and SNMP; Routing holds BGP.

Four backends, free in every tier and usable together: PostgreSQL (one typed table per probe type, range-partitioned by month, 12-month retention by default, optional TimescaleDB mode); InfluxDB through the v2 write API, which InfluxDB 3 also accepts; Elasticsearch, one document per result in daily or monthly indices, with Kibana saved objects; and Prometheus, as an exporter endpoint (127.0.0.1:9102 by default) that exposes the latest result of every probe as gauges for scraping or remote_write. Stdout and file (JSON lines) outputs are also available for debugging, air-gapped collection and log shippers. Each probe names the backends it writes to, and one slow or failing backend never blocks the others.

Everything is declared in YAML: a main file (/etc/trcr/master.yaml) plus any number of conf.d fragments that carry probes, inventory and alert rules, merged in alphabetical order. A probe entry names its type, target, interval, timeout and the backends it writes to; agents: pins it to specific agents and preferred_agents: gives an ordered failover list. Unknown keys fail the load with the file and key named, trcrd validate checks a configuration without starting it (CI-friendly), and trcrd init writes a commented starter config. There is no database setup and no UI configuration step. TRCR runs as a daemon for continuous monitoring, and trcrd run <type> <target> executes a single probe for scripts and cron.

No. TRCR runs as an unprivileged user and uses Linux capabilities for the one thing that needs them: raw sockets for ICMP ping and traceroute (NET_RAW). The ping engine tries unprivileged datagram ICMP first and falls back to a raw socket only when needed. The installer ships hardened systemd units that grant those capabilities to the service alone. An agent that only runs HTTP, DNS, TCP or SSL probes needs no capability at all.

Yes. The same daemon is published as a container image, ghcr.io/trcrdev/trcrd, for linux/amd64 and linux/arm64. A Compose file runs a master, an agent and a PostgreSQL results store on one host; Podman users get systemd quadlet units. Agents run with the NET_RAW capability on the host network so ping and traceroute measure the host's real path. The walk-through is in the public documentation.

TRCR is made by NameVerse, Inc., a company in Palo Alto, California (425 Page Mill Rd, Suite 200, Palo Alto, CA 94306), which also publishes under the name TRCR Networks. The product was founded in 2025. The public documentation and Grafana dashboards are published at github.com/trcrdev, and the live demo at demo.trcr.dev runs on the company's own TRCR mesh. You can reach the team at [email protected].

The daemon is a single static Go binary with builds for Linux on amd64, arm64 and 32-bit ARM (Raspberry Pi OS included), macOS on Intel and Apple silicon, and Windows on amd64, all downloadable from trcr.dev/download/latest with signed SHA256SUMS. The same binary is published as the container image ghcr.io/trcrdev/trcrd for linux/amd64 and linux/arm64. Masters and agents can mix platforms freely; inside a container the master's hostname is pinned, because the licence fingerprint derives from it.

One command on a fresh Linux host (Debian, Ubuntu, RHEL or Fedora): curl -fsSL https://trcr.dev/install/install.sh | sh -s -- --all-in-one --email [email protected] --company "Your Co". It installs the master, a local agent, a PostgreSQL results store, Grafana with the shipped dashboards and starter probes, then emails a verification link for the free licence; the host finishes setting itself up seconds after you click it. The whole thing takes about a minute. Add another site with sh -s -- --agent on that host and sudo trcrd enroll-agent <ip> --code XXXX-XXXX on the master. Re-running the install command upgrades in place.

At scale TRCR switches to a batch mode that pings every target in parallel from one configuration entry and one socket, so a sweep of thousands of targets completes in seconds rather than minutes. For each target it records minimum, average, maximum and standard-deviation round-trip time, packet loss, and jitter — the variation between consecutive replies that VoIP and video care about. Intervals can go down to 1 second (5 seconds for every other probe type), and count is capped at 100 packets per run so a misconfiguration can never turn the fleet into a flood source.

TRCR runs the traceroute on a schedule, in UDP mode by default (ICMP Time Exceeded replies identify each hop), records every hop's address, hostname and latency, and hashes the path. When the path differs from the previous run — an ISP failover, a BGP shift, a misconfiguration — it sets path_changed, keeps the previous path for comparison and can fire the traceroute_path_change alert rule. Each hop is also enriched with its autonomous system, so an AS-path change is detected separately from a hop-level change. You see routing changes as they happen, with history, instead of running traceroute after the fact.

Every HTTP/HTTPS probe records the full request lifecycle: DNS resolution time, TCP connect time, TLS handshake time, time to first byte (TTFB), transfer time and the total, plus the status code and status text, body size and SHA-256, redirect count, final URL after redirects, and a curated set of response headers. You can set the method, headers and body, basic auth or an API key, an expected-status list and response validation. A transport failure records status 0 rather than nothing, so dashboards show the outage instead of a gap. The breakdown isolates whether a problem is at the DNS, network, TLS or application layer.

Yes. TRCR ships a native TCP throughput probe — an in-process iperf3 replacement, so no external tool is installed. One agent dials another agent's throughput server (port 5202 by default) over mTLS using the certificates the master issued, and streams for a bounded duration or byte count, whichever comes first (up to 60 seconds per test). It reports bandwidth in bits per second, bytes sent and received, connect time and, on Linux, TCP retransmits, which indicate congestion. Useful for capacity planning and for verifying a link after a change.

The ssl_expiry probe completes a TLS handshake with the target (SNI configurable), then validates the chain separately against the system roots or a CA bundle you name. It reports days remaining, the validity window, whether the chain verifies, issuer, subject, serial, signature algorithm, key type and size, the subject alternative names, and the negotiated TLS version and cipher suite. Because the handshake and the validation are separate steps, a broken or expired certificate still produces a full result with cert_chain_valid=false rather than an error, so the alert can say what is wrong.

Yes. The snmp probe (Performance bundle) uses SNMPv3 and bulk-walks ifTable and ifXTable, emitting one result per interface: in and out bits per second, utilisation against the negotiated speed, error and discard rates per second, operational and administrative status, and a flap flag when the status changed since the last poll. Device rows carry the interface census, CPU load, memory use and sensor alarms, and each sensor gets its own row. It is the probe that points at the specific link behind an end-to-end loss figure. Credentials come from environment variables or TRCR's sealed secrets, never from plain YAML.

Two Reachability probes cover failures that plain ping misses. The mtu probe sends ICMP echoes with the DF (don't fragment) bit set and binary-searches for the largest size that gets a reply, between 576 and 1500 bytes by default, so an MTU black hole on a VPN or overlay tunnel is reported as a number rather than as mysterious stalls. The ntp probe sends SNTP queries (RFC 4330) to each server in a pool and computes offset, delay and jitter from the four NTP timestamps, reporting the best server's offset and stratum and whether a quorum answered. Clock drift is what breaks TLS validation and log correlation; this catches it early.

The master is the central scheduler and the deployment's certificate authority: it runs its own probes, pushes probe assignments to agents, receives results over mTLS, fans them out to every backend, evaluates alert rules and, optionally, heartbeats to api.trcr.dev. Agents are the same binary in agent mode, deployed where you need a vantage point. An agent enrols once with a single-use token or pairing code, pulls the probes assigned to it, runs them on schedule and ships results back in batches. Results are tagged with the agent that produced them, so one dashboard can be filtered by site.

Once two or more agents are enrolled, the master synthesises a ping from every agent to every other agent — every 60 seconds by default — so N agents produce N × (N − 1) measurement paths with no per-agent configuration. 10 agents give 90 paths. Because both directions are measured, asymmetric problems (good one way, bad the other) are visible immediately. Traceroute, HTTP, DNS and throughput probes between sites are one entry each in the same configuration file, and agents: or preferred_agents: decides which vantage points run them.

No. The master's YAML file defines the whole topology. Agents poll the master for their assignments (every minute by default), so a change on the master reaches every agent within about a minute without restarting anything. Each agent receives only the probes it is responsible for, and trcrd probes on the master lists exactly what each agent runs. Scaling from 2 sites to 200 is the same file with more agents enrolled.

Yes. A master on its own is a complete monitoring daemon: it runs every probe type against any number of external targets (up to your licence's monitor limits) and writes to all backends. The agent architecture is optional — add agents when you need measurements from other sites, or when you want site-to-site paths and throughput.

With mutual TLS, TLS 1.3 only, in both directions. The master is its own certificate authority (ECDSA P-256) and issues each agent a 365-day certificate at enrolment; agents renew automatically at 75% of the certificate's lifetime. Enrolment uses a single-use token or a pairing code that the master claims. The master refuses any agent certificate that names the master itself, so an enrolled agent cannot impersonate it, and every result is attributed by the certificate that delivered it, not by a field the agent filled in. Revoking an agent takes effect on a running master within 5 seconds.

Yes. The licence is an Ed25519-signed file checked against the local clock, so the master starts and keeps running without reaching the internet. The heartbeat to api.trcr.dev can be disabled entirely (heartbeat.enabled: false), and when it is enabled but unreachable, probes keep running under the cached licence. Backends are inside your network. The only outside dependencies a probe can have are the ones you configure as targets.

Only licence telemetry, and only when the heartbeat is enabled: the licence ID, daemon version, machine fingerprint, agent count and uptime, sent at most hourly. Probe targets, probe results, dashboards, alert rules and network topology never leave your infrastructure; they go straight from the master to the backends you run. The self-service portal holds account details, licences and an audit log of portal actions. Details are on the security page.

Yes, free forever: up to 5 agents and 50 monitors across all four bundles — 15 Web, 20 Reachability, 10 Performance and 5 Routing — with all data backends (PostgreSQL, InfluxDB, Elasticsearch, Prometheus) and alerting included. A monitor is one target for one probe type, so the Web allowance covers, say, 10 HTTP checks, 3 certificates and 2 DNS records. No credit card. The free licence is issued within seconds of verifying your email and auto-renews annually at no cost.

A paid licence is tied to the machine fingerprint of the server running the TRCR master; agents are not licensed individually and never count against a limit. Licences are sold as bundles (Web, Reachability, Performance, Routing), each with a monitor cap per tier — Starter, Growth or Pro — that sets how many targets that bundle's probes can watch. Backends and alerting are included in every tier. Contact sales to discuss the right bundles and tiers for your deployment.

A monitor is one unique target — an IP address, hostname or URL — probed with a given probe type. The same host checked by ping and by HTTP is one monitor in the Reachability bundle and one in the Web bundle. Agents are deployment points, not targets, so they never count against your monitor caps unless you also probe them as targets. The master enforces the caps per bundle at startup and reports every overflow at once.

Yes, with a restart of seconds. Upgrading is a licence-file swap on the master: run trcrd license claim once the new licence is issued and the master restarts itself to load it. Agents keep running their assignments and buffer results while the master is away, and nothing about your configuration, dashboards or stored data changes. Downgrading works the same way.

Through the self-service portal at trcr.dev after creating an account: view active licences, download licence files, track deployments and reach support. On the host, trcrd license status shows what the master is running under, trcrd license request asks for a free licence and trcrd license claim installs an issued one.

The free tier is $0 forever (5 agents, 50 monitors across the four bundles). Paid bundles are flat annual prices per capacity tier. Web (HTTP, SSL expiry, DNS): $300, $900 or $2,500 per year for 50, 200 or 1,000 monitors. Reachability (ping, batch ping, TCP, traceroute, liveness sweep, NTP, path MTU): $300, $900 or $2,500 for 100, 500 or 2,500 monitors. Performance (native throughput, DNS propagation, SNMP): $600, $1,800 or $4,500 for 25, 100 or 500 monitors. Routing (BGP): $2,000, $6,000 or $15,000 for 10, 50 or 250 sessions. All four bundles at the same tier are 20% off: $2,560, $7,680 or $19,600 per year. A 3-year term takes a further 15% off. Enterprise pricing covers unlimited monitors and agents, dedicated support and custom SLAs. The full matrix is on the pricing page.