Reachability
Which server can reach which — the matrix that separates a host problem from a firewall problem.
Fleet → Reachability is a grid: every agent down the side, every agent across the top, and whether each can reach the other.
What it answers
Is this a host problem or a network problem?
| Pattern | Means |
|---|---|
| One row red | That server cannot reach anything — its own networking, or it is down |
| One column red | Nothing can reach that server — it is down, or it is firewalled off |
| A block red | A subnet or security-group boundary |
| Scattered red | Usually a genuine network problem rather than a configuration one |
Establishing that distinction by hand takes about twenty minutes and several SSH sessions. The matrix does it in a glance.
How it is built
Agents probe each other on a schedule. It is the same probe machinery pointed at peers.
Why it is agent-to-agent
Reachability from the monitoring system is a different question and a less useful one. The monitoring system usually sits somewhere with broad access; your application servers do not.
The path that matters is the one your traffic takes.
After a firewall change
The matrix is the fastest way to verify a security-group or firewall change did what was intended — and, more importantly, only what was intended. Compare before and after.
Alerting
Lost reachability between two agents raises an alert. Scope it: some pairs are not supposed to reach each other, and alerting on those trains people to ignore the ones that matter.
Where this behaviour lives: backend/internal/service/agent_mesh_svc.go, frontend/src/app/agents/mesh/. If the code and this page disagree, the code is right — please fix the page.
Part of Fleet — The agent on each server: what it collects and what it may be asked to do.