ARCTIC RELAY MONITOR / OPERATOR GUIDE
Know what
you’re looking at.
A practical reading guide: connect a node, establish a baseline and follow a signal to its source. These examples use the application’s real screens.
← Product overviewFIRST CONNECTION
Verify the server.
Then trust the measurements.
Prepare the connection
Use Add VPS to enter the Ubuntu server connection and select the SSH key. Keep account details in the application, never in a public screenshot.
Verify the host identity
Compare the displayed SSH fingerprint with the provider console or another trusted source before accepting it. Fetching a key alone does not authenticate the server.
Review and connect
Run the read-only checks. Review and approve any required agent installation separately, then wait for a fresh, authenticated sample.
Establish a baseline
Open Details, confirm the connection checks and review CPU, workload RAM, disk and peer readings. Return to Fleet for the broader picture.
FOUR DISTINCTIONS THAT MATTER
Read the source, not just the number.
- Mac RTT / Peer RTT
- Mac RTT describes the operator’s connection to the VPS. Peer RTT describes measurements between VPS neighbours. A problem on one path need not affect the other.
- Availability / SLA
- Availability reflects monitoring observations from this Mac. A displayed 100% is not an independent provider SLA measurement.
- Zero / Not configured
- A zero and an unavailable source are different states. Check the source status before interpreting queues, throughput or TLS fields.
- Health / Capacity
- Health describes current findings. Capacity estimates use local history to help plan ahead; they do not purchase or scale servers.
01 / Fleet / expanded view
Read one card before opening its details
Expanded cards expose resource utilisation, uptime, peer RTT, Mac RTT, outbound queue and network rates directly in the fleet view.
When to use it
Choose this layout when a few nodes need closer attention. Use Details for the selected node; change back to compact mode when the whole fleet matters more.
What to read
- Uptime and resource bars
- Peer RTT versus Mac RTT
- Queue and network-rate context
02 / Node details / advanced telemetry
Separate memory pressure from memory accounting
Workload RAM, allocatable memory, provider balloon and memory pressure appear beside optional process, file-descriptor, SQLite and network counters.
When to use it
When RAM looks high, check workload and pressure first. Provider ballooning alone is not evidence of an application memory leak. The checkboxes control which metrics are displayed.
What to read
- Workload, allocatable RAM and PSI
- Optional Relay process and SQLite data
- RX/TX totals and error growth
03 / Node details / capacity and history
Wait for a useful trend
Resource summaries sit above storage, RAM and connection forecasts, followed by disk, latency, availability and queue history.
When to use it
Use the history to distinguish a short spike from sustained growth. Read a forecast together with the amount and consistency of the data behind it.
What to read
- Average and peak resource use
- Local trend estimates
- Availability and queue history
04 / Node details / throughput
Distinguish server traffic from Relay activity
The network graph shows inbound and outbound server traffic while the Relay graph remains flat. Source status below the graphs explains why these measurements differ.
When to use it
Confirm that the required source is configured before interpreting a zero. Network bytes can change even when there is no configured Relay telemetry.
What to read
- Inbound and outbound network rates
- Relay counters when configured
- Agent version and telemetry status
05 / Compare / compact cards
Keep several dimensions beside each other
A compact comparison places CPU, memory, disk, swap, load, availability, latency and error rates on each node card. Provider and region labels support the investigation.
When to use it
Look for a shared pattern across nodes before narrowing to a single server. Use a common period so the values are comparable.
What to read
- Resources, load and swap
- Peer and monitoring latency
- Provider and region context
06 / Timeline / local event journal
Follow problems and recoveries through time
The horizontal axis is time and the vertical axis is severity. Filters select problems, recoveries, capacity events and renewals for a fleet or one VPS.
When to use it
Start with a short period around an incident, add recovery events, then focus on the relevant node. In the application, hovering explains an event and clicking keeps it selected.
What to read
- Time and severity
- Problems, recoveries and planned events
- Per-node and fleet filters
A REPEATABLE OPERATOR ROUTINE
Scan. Investigate. Review.
Read the current state
Check Fleet and sample freshness. Open nodes that need attention. Review memory pressure, disk, configured Relay counters and slow peer links.
Confirm the recovery
Check a fresh sample, compare the affected metrics and inspect the incident history. End maintenance when the planned work is complete.
Look beyond a single spike
Compare a longer period and its previous window. Review recurring incidents and capacity trends before deciding what needs intervention.
READING THESE EXAMPLES
Keep the limits visible.
The screenshots show a particular session, including unconfigured Relay fields and an empty Timeline. They demonstrate the interface and the available evidence, without substituting invented activity.
These explanations draw on the Arctic Relay Monitor operator manual and the current application’s documented behaviour. Features that depend on optional telemetry remain dependent on that source. This concise guide does not replace the application’s confirmation steps or server-access requirements.
Back to Monitor overview ↗