Task · TSO-0038

Peer-relay connection dimension on node connectivity metrics

Description

Peer relays went GA 2026-02-18. Investigate whether the API or device data (DevicesRich fields, node metrics endpoint) exposes relay designation or relay-vs-DERP-vs-direct connection usage - the public API surface is unconfirmed, so first step is a live-capture check against .capture/ style fixtures. If present, add it as a connection-type dimension to the existing node connection metrics and a peer-relay health panel; if absent, record the negative result and park.

Acceptance Criteria

Definition of Done

Implementation Notes

PRE-WAVE-3 RESEARCH, 2026-08-30 — ALREADY DELIVERED, and the negative half of AC#1 is proven offline.

AC#1, the “which relay fields exist on the wire” question, has three parts and all three are now answered:

AC#2 is satisfied: all three signals are catalogued and carry the visualized disposition in internal/catalog/signal_dispositions.json, and tailscale.node.peer_relay.endpoints is alertable as well. The node-metrics endpoint is the only surface that carries peer-relay data and it is the one already wired.

Final Summary

Refuted-and-delivered: the peer-relay designation is absent from the REST API (vendored AND live spec, both greppped for “relay” with zero hits) and from rich device data, but present on the tailscaled node-metrics endpoint, where all three peer-relay series are already curated (internal/collector/nodemetrics/curated.go:59-67) and all three carry the visualized disposition.

View the source file on GitHub