ARCTIC RELAY MONITOR IN DEVELOPMENT

Your fleet.
A clearer picture.

A native macOS workspace for operators of Ubuntu VPS fleets. Follow server health, understand peer connections and investigate incidents from one place.

macOS applicationUbuntu metrics agentLocal operational history

01 / FLEET OVERVIEW

The fleet, in one view

Fifteen registered VPS nodes share one overview. Resource bars, fresh-sample indicators and small history charts help an operator decide which node to open next.

Fleet / compact view
The 15-node fleet and availability figures are a captured operating example, not a capacity limit or an uptime guarantee.

When to use it

Start here at the beginning of a shift. Search for a node, scan the summary, then use Needs Attention to narrow the investigation.

What to read

  • CPU, workload RAM and disk
  • Node health and sample freshness
  • Compact or expanded layouts

02 / Node details / connection diagnostics

Find the layer that needs attention

The Amsterdam detail view separates server reachability, the pinned SSH identity, the monitoring tunnel, agent authorization and the metrics schema. Current resources and adjacent-peer readings remain in the same view.

Node details / connection diagnostics
The connection identity has been removed from this public screenshot. Diagnostics show the state of the connection; they do not repair the VPS automatically.

When to use it

Use the connection checks when a sample becomes stale. They help distinguish an unavailable server from a problem along the monitoring connection.

What to read

  • SSH reachability and trusted identity
  • Agent authorization and schema
  • CPU, RAM, disk and peer RTT

03 / World map / infrastructure view

Put the network in context

A world view connects the registered VPS regions and places measured peer delays alongside the links. Geography gives the operator context when a distant connection becomes slow.

World map / infrastructure view
Locations are approximate infrastructure labels. This is not a map of users or individual messages. In this capture, monitoring is live while Relay message counters are not configured.

When to use it

Locate a region, inspect its neighbours and open the corresponding node in the application. Follow the measured link quality before drawing conclusions from distance alone.

What to read

  • Operator-entered VPS regions
  • Peer links and round-trip delay
  • Node status across regions

04 / Adjacent peer mesh / link history

Read both sides of a slow link

Each link card brings together directional round-trip readings, loss and recent history. The captured fleet has 30 live directions and three links marked for review, even though the node summary is healthy.

Adjacent peer mesh / link history
Peer probes are measured between VPS nodes. They differ from the Mac-to-VPS monitoring path and do not prove that application messages are being delivered.

When to use it

Check whether a delay affects one direction or both. Node health and peer-link quality answer different questions and should be read together.

What to read

  • Directional RTT and loss
  • P95 latency and jitter
  • Selectable history windows

05 / Compare / charts

Compare the same metric across the fleet

CPU, workload RAM, disk use and peer latency are aligned across nodes. The overview makes outliers visible without opening fifteen detail windows.

Compare / charts
The capacity horizon is a local estimate from available history. It is not a promised service lifetime or an instruction to purchase capacity.

When to use it

Use Live for a current spike. Switch to an average window for a capacity decision, then compare an equal previous period where available.

What to read

  • Live, 1-hour, 24-hour and 7-day views
  • CPU, RAM, disk and latency
  • Bottleneck and capacity context

06 / Incident Center / operational history

Keep the history behind an incident

An incident has a lifecycle: it opens, develops, recovers and closes. This screen groups the history, highlights correlated bursts and keeps maintenance controls close to the affected nodes.

Incident Center / operational history
Zero active incidents can coexist with a substantial history. Maintenance and mute controls suppress notifications; monitoring and the local journal continue.

When to use it

Review what changed, add an operator note and temporarily suppress notifications during planned work. Keep collecting measurements while the work is in progress.

What to read

  • Active and closed incidents
  • Correlated event bursts
  • Notification and maintenance controls

HOW IT FITS TOGETHER

Observation stays separate
from message delivery.

01

Ubuntu VPS

A read-only agent gathers a bounded set of system measurements and configured aggregate Relay counters.

02

Verified SSH connection

The Mac reads through a trusted SSH connection to a private agent socket. Monitoring needs no public metrics port.

03

Operator workspace

Fleet views, local history and incident context turn measurements into information an operator can act on.

Monitor does not participate in message delivery. Its telemetry excludes message contents and sender or recipient identities. Installation, updates and commands are separate operator actions.

PUT THE SCREENS TO WORK

From first connection
to the daily check.

Learn how to read the measurements, recognise missing data and choose the right view for an investigation.

Open the operator guide ↗

Application captures: 16 September 2026. Readings describe the captured session. The website presents the application; it is not a live monitoring console.

Arctic Relay Monitor

Zoom in for small labels. Scroll across the screen to inspect details.