Skip to main content

Topology: the Traffic tab

The Topology page (/topology) opens on the Traffic tab. It draws one project's services as cards, and the application traffic Console observed between them as lines. It answers "what talks to what, over which port, and where does it run?". The page needs hosts:read for the project.

The map is built from the same graph as the page's other tabs (GET /api/v1/topology/graph). Lines are traffic that host agents saw in the time range chosen in the page header. Nothing on the map is guessed except the internet paths, which are worked out from addresses and routes (see Internet paths).

What the map shows​

Columns​

Cards sit in role columns, left to right:

ColumnWhat goes there
ClientsMachines that only send traffic, and idle machines
EntryLoad balancers, floating IPs, and the namespace that receives ingress traffic (the gateway)
ApplicationsNamespaces, other than those below
In-cluster dataNamespaces that send nothing and are called by other namespaces (for example redis)
Data & servicesMachines outside the cluster that others call: databases, messaging, storage

The columns come from the traffic itself, never from names, and from the overview: hovering, focusing or showing platform traffic does not move a card.

Each card has one row per port it is reached on, for example 5432 postgresql. A line lands on the row of the port it used, and lines into the same port merge into one arrow just before the card.

Provider boxes​

A host's provider decides its provider box. The provider is, in order: the host's provider tag (set on the host's Tags, for example provider=hetzner_robot or provider=servercore), else the provider the agent read from the machine's instance metadata (AWS, Google Cloud, Azure, Oracle Cloud, DigitalOcean, Hetzner Cloud), else the host's cloud source identity. The box is named from the provider, with the provider's own logo where Console has one (Hetzner Cloud, Hetzner Robot, Servercore, PS Cloud; AWS, Google Cloud, Azure, Oracle Cloud and DigitalOcean are named with no logo; any other tag value is shown as written), then its region when all its machines are in one (see Regions and countries), the network it spans and its range (proxima_production_network 10.10.0.0/16) and the name of the cloud source. Tag values are matched without regard to case, spaces or hyphens: Hetzner Robot and hetzner_robot are one provider. The tag value other is reserved and is ignored, in any letter case and with any surrounding spaces: the host's provider then comes from its instance metadata or its cloud source, as if it had no tag.

The provider box holding the Kubernetes cluster (or, with none, the most hosts) spans the columns. Every other provider's box is drawn below it, its hosts still in their role columns. Hosts with no provider from any source, that are not Kubernetes nodes, go into a neutral Other hosts box to the right, grouped by network. A project with no provider at all draws no provider box: its hosts keep their role columns.

Inside the provider box, network boxes group hosts by private subnet, as before.

Regions and countries​

Every host, server and load balancer is placed by the first of these that says where it is:

  1. its region tag (on the host's Tags, for example region=fsn1 or region=uz-1b; a zone names its region and keeps the zone). other and an empty value are ignored, as for provider;
  2. its cloud account's placement (Hetzner Cloud servers and load balancers);
  3. what its agent read from the machine's instance metadata (AWS, Google Cloud, Azure, Oracle Cloud, DigitalOcean, Hetzner Cloud);
  4. the country of its first public address, from an offline copy of DB-IP's IP to Country Lite. For a host that is its first public IPv4 address, because Console records a host's addresses from its interfaces' IPv4 addresses only; a cloud server or load balancer uses its public IPv4 address, else its IPv6 one (the country file and its lookup handle both). Console looks the address up itself; no address is sent anywhere.

Codes are looked up in Console's region catalog (regions.json): nbg1 is Nuremberg, Germany; uz-1 is Tashkent, Uzbekistan. A code the catalog does not know is shown as written, with no city and no flag; it is never guessed.

  • One region: the provider box's caption names it after the provider, with the country's flag: Servercore · (Uzbekistan's flag) Tashkent · uz-1.
  • Two or more regions: the provider box holds a region box per region, each named with its flag, city, code and machine count: (Germany's flag) Nuremberg · nbg1 · 14 hosts. Machines with no location sit in an Unknown region box, and a machine placed only by its country gets a box named after the country, with its flag (Germany · 1 host). A network that spans regions is drawn once in each, in the same colour. Region boxes are laid out one below the other.
  • Zones never make a box: a host's zone is on its card's second line (zone uz-1b).
  • The details panel says it too, in its header on two lines above the name: the provider's logo, the flag and HOST · SERVERCORE, then TASHKENT · UZ-1 · UZ-1B. A location from the address adds from IP address to the second line. A Kubernetes node's panel shows its own place; a namespace's shows the place of its first node.
  • Flags are pictures, not emoji. On the map a flag is part of the box's caption, which is drawn as one image, so its country is the caption's city or country name. In the details panel, hovering the flag names its country.

IP geolocation by DB-IP (CC BY 4.0).

Kubernetes nodes and namespaces​

The cluster box starts with the cluster's nodes, one card each:

  • KUBERNETES NODES · CONTROL PLANE: nodes that run a control-plane service (rke2-server, k3s in server mode, or kube-apiserver/kubelet together with etcd).
  • KUBERNETES NODES · WORKERS: every other node. A worker card adds N app · M platform workloads, counting the workloads Console places on that node.

A node card shows its IP, instance type and location when the cloud source knows them, and a status dot.

Below the nodes, the NAMESPACES band holds one card per namespace. Under the title, node chips say where the namespace's workloads run and how many, for example w01 13 · w02 2 · w03 2. The chip label is the node name with the suffix all nodes share removed and shortened (worker01-rke2 becomes w01); if two chips would collide, the longer name is used for every chip in that environment.

  • Hover or select a namespace to draw dotted links to the nodes it runs on, with a workload count at each node.
  • Hover a worker to draw links down to every namespace with workloads on it, and to light that node's chip on each card.

A node's own application traffic (host-network pods and node agents) merges into one cluster nodes junction on the cluster box's edge. Hovering or selecting a node shows that node's own lines instead.

Idle services​

A service with no application line in the time range is drawn in place, in the column and network box it belongs to, as a dashed card with the subtitle no traffic. The Idle services switch hides them.

Temporary client ports​

Card rows and lines leave out ports in 32768–60999 (the Linux range for outgoing client connections) unless the destination actually listens on that port. The details panel says how many were hidden, for example "2 temporary ports hidden (59210, 60932): client ports in 32768–60999 that nothing here listens on."

Lines​

Each line is coloured by what the destination port is, from the service name first and then the port number:

KindExamples
Databasepostgres, mysql, clickhouse, redis, mongo; 5432, 3306, 8123, 9000, 6379, 27017
Messagingnats, rabbitmq, amqp, kafka; 4222, 5672, 9092
Metrics / logsvminsert, vmselect, vmstorage, victorialogs, loki, otel, prometheus, anything named exporter or metrics
SSH / accessssh, teleport; 22, 2222, 3022–3025
HTTP / mesheverything else

A metrics endpoint of a database (for example clickhouse metrics or postgres-exporter) counts as metrics traffic.

Every line is drawn 1.5 px wide on screen at any zoom, and 2.5 px while it is hovered, selected, traced or part of a focus. Zooming in makes cards bigger, never lines thicker.

  • Solid lines were seen recently. Dashed lines were seen in the range but not recently.
  • The ingress path from the load balancer through the gateway keeps its own style.
  • Legend filters. Open Legend (over the map's top-right corner) and click a kind to hide its lines, stubs and junction counts; click again to show them. Filters last for the session only. Esc on Legend or in its list closes the list; an Esc pressed elsewhere is left to what it was meant for. With the details panel open and too little room beside it for the list, Legend does nothing and says why, in its tooltip and to a screen reader alike (Close the details panel to show the legend).
  • Path trace. Hover a line to trace it: lines that feed where it starts and lines that leave where it ends, up to four hops each way. Everything else dims. The tooltip shows from → to :port, the kind, the connection count and when it was last seen.
  • Entry line rate. The tooltip and the details of a load balancer's entry line say N req/s at the load balancer (Hetzner, last 5 min): the load balancer's requests per second, averaged over the 5 minutes up to its newest reading. It is shown while that reading is under 10 minutes old, and only with metrics:read. It is the whole load balancer's rate, so every entry line from one load balancer shows the same number. The line keeps its width.

Routed lines​

Lines run in the gaps between cards, with rounded corners, and never across a card. A line that lands on several port rows of its host runs as one route and splits into its port landings only just before the host; the lines from one card into one host share that route.

  • Drawn as thin as every other line. Lines do not show volume: the connection count is in the tooltip and the details panel.
  • Coloured by its lines' kind when they all share one; a neutral of its own (near-black, near-white in dark mode) when it carries lines of several kinds. In dark mode the live flow on such a route is a deep cyan rather than the pale flow colour, which would not show on it. The ingress path keeps its own style.
  • Dashed only when every line on it was not seen recently; it moves (Live flow) when any of them was.
  • Routes into the same host end at one point left of it, where they split into the port landings, and join one another on the way where they can.
  • Click a route to open what it carries. A route carrying one line — however many port rows it lands on — opens that line's own details. A route carrying two or more lines opens N lines to host, one row per line with its kinds, its ports and its connections; clicking a row opens that line's details, and Back returns to the list.
  • Hover a route to light its lines, their port rows and the host; its tooltip gives the lines and port landings (1 line to gateway · 3 port landings), the ports, the kinds and how many of the lines are live. Anything that lights a line — a hover, a trace, a search, a selection — lights the route carrying it.
  • The legend filters, Traffic lines, Workloads and Idle services switches hide a route when they hide all of its lines; with some of its lines filtered out, it takes the look of the lines still drawn. Pointing at a cluster node hides the routes whose lines its own lines replace.
  • The routes are worked out once the map is laid out (the first draw, a focus, an update that changes what is drawn, the Internet switch), never when you pan or zoom. Idle services the switch hides are still avoided, so turning it back on never puts a card under a line.
  • Every line between two cards is routed. A cluster node's own lines and a namespace's placement links (shown while you point at the node or the namespace) are routed in idle time once the map is laid out, or when first shown if that is sooner, and kept until the next layout; a router's line into its cluster box ends on the box's edge. Lines into a Kubernetes node rise into it from below, because node cards stand too close side by side to arrive between them. The internet paths keep their own gutter routes.
  • A line the router cannot place is counted and, when shown, drawn straight: the coverage chip says N lines not routed, whether or not those lines are on screen. On Proxima's own map every line is routed.

Switches​

The tool rail's Layers holds the five switches as checkboxes, each with its key, and Platform traffic below them. They work in full screen too. Your choices are remembered in this browser.

SwitchDefaultWhat it does
Traffic linesonOff hides every line; cards and boxes stay. Live flow and the legend filters are disabled while it is off
WorkloadsonOff hides namespace cards and every line touching them
Live flowonMoving dashes on live lines. Off shows arrowheads instead. Always off when your system asks for reduced motion
Idle servicesonOff hides the "no traffic" cards
InternetoffShows the internet paths

Platform traffic (in Layers, or Show platform traffic in the coverage chip's notes) draws platform lines (Kubernetes system traffic, node agents) faded. They are hidden until you turn it on.

What the map leaves out is a small ⓘ chip over the map's top-right corner, left of Legend, in a few words (446 hidden · 303 outside · +2). Click it for all of it, under What this map leaves out: hosts not reporting (with a link to agent configuration when none do), platform lines hidden, outside destinations, capped hosts, and connections and cluster lines not drawn, plus the platform toggle. The chip is not shown when the map leaves nothing out.

While the details panel is open, the row of chips and Legend moves left of the panel. Where only their icons fit there, they show as icons, each keeping its name and tooltip; where not even those fit, the row stays at the corner, under the panel. The chip's notes, like the Legend list, open inside the map, clear of the tool rail and of the panel, and scroll when they are taller than the room.

Internet paths​

Turn on Internet to see how the estate reaches the internet and how the internet reaches it. An Internet node appears above the map with the number of internet addresses reached in the range.

  • Out through the NAT gateway. A private network gets one path to its NAT gateway, then one from the gateway to the Internet. The gateway is the host that holds the address of the network's default route (0.0.0.0/0), as recorded by the cloud source. The cluster box counts as its nodes' network. A network with no default route recorded draws no path, and its panel says "no default route recorded for this network".
  • Out directly. A host with a public address, or a cloud public IP, gets its own path. Private, loopback and link-local addresses (169.254.x.x, fe80::) are not public.
  • Way in. Each load balancer and floating IP gets a path down from the Internet.

These are paths, not measured traffic. They show which way traffic would go, worked out from addresses and routes; they carry no counts and are left out of line totals. The map does not know which internet addresses each host talked to, only the total.

Click the Internet node for the Internet access panel: the NAT gateway, each network (click one for its subnet, its cloud network's name and range in the Network and Range rows, each with its own copy button, its gateway and the hosts → gateway → Internet path), the directly connected hosts and the ways in.

Details panel​

Click any card, line or the Internet node to open the details panel on the right. Its top row holds Back (once you have moved from one item to another), the item's kind and name (hover a long one for all of it) and ✕ (Close details). The camera fits the selection beside the panel, zooming in no closer than 1.5× (so two neighbouring cards are not blown up past readable size); under a focus, a card, line or route that only the focus draws opens as the focus draws it; Esc closes the panel and restores the whole map. Clicking a row in the panel (a caller, a node, a workload) moves to that item, and Back returns to the previous one.

SelectedThe panel shows
Host, server, load balancerWhere it is, above its name (provider logo, country flag, provider, city, region, zone; from IP address for a country from the address); hostname, IP and subnet, each with a copy button; Open host in Console; ports, callers and calls out; Reached on with address:port; Called by and Calls; Metrics (below)
Kubernetes nodeWhere it is, above its name, as for a host; hostname, IP and type; Open host in Console; app and platform workloads, namespaces and role; app workloads by namespace; Metrics (below)
NamespaceWhere it runs, above its name: the place of its first node, as for a host; the name with a copy button; Runs on, a bar and a row per node with IP, count and share; workloads grouped by node; Reached on, Called by and Calls
LineFrom, to, port, kind, connections, last seen, which agents saw it, processes, and the workload pairs behind it; on a load balancer's entry line, the load balancer's requests per second (see Lines)
Route of two or more linesN lines to host, its port landings and how many lines are live, from and to, and one row per line with its kinds, ports, connections and whether it is live; each row opens that line (a route of one line opens that line directly)
Internet, networkSee Internet paths
  • Workloads. Job and CronJob runs fold into their job (name with "N job runs", or "cron + N job runs"). Groups longer than eight collapse behind Show N more. Click a workload to select it: a link runs to its node, only its own lines stay lit, and the camera fits them. Click again to clear it.
  • Copy buttons put the value on the clipboard and confirm it ("Copied IP: 10.10.3.11"). If the browser refuses, the text is selected and the message says "Selected. Press Ctrl+C (⌘C) to copy".
  • Focus this opens the focus view for the selected item: its neighbours pulled out and the rest faded. While a focus is on, a chip over the map's top-right corner names it, with Esc to exit and Details.
  • Open cluster in Console ↗ appears at the top right of the cluster box, and in a namespace's panel, when you have assets:read for the project. It opens the cluster's page (/clusters/:id).

Metrics​

A host's or a Kubernetes node's panel has a Metrics section when you have metrics:read for the project. It has a range of its own, separate from the page's time range: Live (the default), 5m, 15m, 1h, 6h or 24h. The range you pick stays for the next panel you open, until you reload the page. The section refreshes with the map. Nothing is drawn on the cards.

  • The table. In Live, one now column, with how old its oldest reading is above the table ("updated 12 s ago"). Over a window, now, avg, min and max, in slightly smaller figures so the four fit. Rows:
    • CPU, named with the host's core count (CPU · 8 cores) when it is known. It is the share of all cores' time, not one core's: 42 % of 8 cores is about 3.4 cores busy (the ⓘ says so).
    • RAM, with what it is of from the host's memory total: in Live, 52 % · 8.3 of 16 GB; over a window, of 16 GB under the row's name, and the four columns are percentages as before. A host with no memory total on record shows the percentage alone.
    • Load. In Live, the 1, 5 and 15 minute averages and the 5 minute average per core. Over a window, the 5 minute average's figures, with the three averages and per core under the row. Over 1.0 per core now it says Above now; over a window whose highest point was over 1.0 per core but is not now, Crossed earlier. Without a core count there is no per-core figure and no flag.
    • Disk, the host's fullest own mount, named. Kubelet, container-runtime (Docker, containerd, rke2 and k3s), snap and pseudo-filesystem mounts are not the host's disks and are left out, here and in the host page's disk meters. With its used and total space: in Live, 71 % · 355 of 500 GB; over a window, 355 of 500 GB under the mount's name. The used figure is the percentage of the total, so the two always agree. A host with none of its own says No host disk reported.
    • Net in and Net out, per second, summed over interfaces.
  • "now" is only ever recent. A row's now is its latest reading only while that reading is recent: within the last 5 minutes in Live, and within two steps of the window's end otherwise (2 minutes for windows up to 6 hours, 10 minutes for 24 hours). An older one reads — (in Live, with no size beside it; over a window, the total stays under the name, as of 16 GB or of 500 GB, but not the disk's used figure), with no data since and when under the row's name; a window still shows its avg, min and max. When every row has gone quiet, the section says No data since … once, above the table; once the host has been quiet for 15 minutes, the Disk row also says No host disk in the last 15 min.
  • Sizes are in binary units, as on the host page (a GB is 1024³ bytes), with one decimal under 10 and none from 10. CPU, Load and the network rows show no limit: CPU's and Load's are in their core count, and a link's speed is not known.
  • Open host metrics opens the host's Metrics tab.
  • Problem signals follow the range. Live lists the signals over their threshold now; a window lists those that crossed it at any point, with now and max. The signals: packet drops (> 1/s), interface errors (> 0.1/s), CPU steal (> 5 %), IO wait (> 10 %), CPU pressure (> 10 %) and conntrack entries (> 50,000). Each says Above now (judged only on a recent reading) or Crossed earlier. With none, it says No problem signals now, or for a window No problem signals in the last 1 hour (and so on). A signal the host does not report is left out. Load per core is on the Load row.
  • A Hetzner Cloud load balancer, or a Hetzner Cloud server with no Console agent, has its own section (below). Any other server or load balancer with no agent says No agent on this server: no metrics. A host with nothing in the range says No metrics in this range; in Live, that is a host silent for the last 5 minutes. If one reading fails, its row says Couldn't load with Retry, and the rest still show.
  • A reading that fails after it has drawn keeps its last values, with a small Last update failed mark beside them, until a refresh succeeds.
  • If you can read metrics in the project but not for this host's environment, the section says No access to this host's metrics and stops asking.

Hetzner Cloud load balancers and servers without an agent​

A Hetzner Cloud load balancer, and a Hetzner Cloud server with no Console agent (for example nat-gw), has a Metrics · from Hetzner Cloud section, with the same range picker, table and states as a host's. Console reads these numbers from Hetzner every 5 minutes (PROXIMA_HETZNER_METRICS_INTERVAL) and keeps them in its own VictoriaMetrics, so the newest reading can be about one interval plus 2 minutes old (about 7 minutes at the default), plus Hetzner's own delay. Live reads the last 10 minutes, and a reading counts as now for 10 minutes in every range.

  • Load balancer: Requests/s, Connections/s, Open connections, Bandwidth in and Bandwidth out. They are the whole load balancer's, not one target's or one service's. Open connections says what it is of, the limit of the load balancer's type: in Live, 1,614 of 10,000; over a window, of 10,000 under the row's name.
  • Server: CPU (as Hetzner reports it), Disk read and Disk write in bytes per second, with operations per second under each, and Net in and Net out.
  • There are no problem signals and no Open host metrics link: there is no host page.
  • No metrics from Hetzner yet: Console holds nothing for this object in the last 10 minutes. It may be new, its cloud account may not have been read since, Console may not be able to reach Hetzner, or the Hetzner project's API budget is running low (other tools on the project, such as the Kubernetes cloud controller manager or Terraform, are using it, and Console holds back to leave them room). A window with nothing says No metrics in this range.
  • Metrics need metrics:read: you can see the object but may not read its metrics. An object from a cloud account that is not pinned to one environment needs metrics:read on the whole project.
  • Access follows the cloud account's current environment. If a super-admin moves the cloud account to another environment of the same project, its objects keep their history: in the details panel, whoever may read metrics in the new environment reads all of it, including the readings from before the move, and a reader of the old environment alone no longer can. Host metrics follow the same rule when a host moves. That rule is the details panel's (the cloud metrics endpoint's) only: the readings taken while the cloud account was in the old environment are stored with that environment, so a metrics query filtered to the old environment (POST /api/v1/metrics/query) still returns them, exactly as it does for a host that moved. They were that environment's when they were taken.
  • A server that runs a Console agent is drawn as a host and shows the agent's metrics. Console does not read Hetzner's for it.

Moving around the map​

  • Mouse wheel zooms around the pointer, about 10 % a notch. On a trackpad, two fingers pan and a pinch zooms. The page does not scroll while the pointer is over the map.
  • Drag anywhere to pan, on the background or on a card. The middle mouse button drags from anywhere.
  • Hand mode (Hand on the tool rail, h, or hold Space): every drag pans and clicks select nothing. Select on the rail turns it off.
  • Tool rail down the left edge of the map: Select (the default: a click selects), Hand and Fit the whole map (Shift+1) on every map tab, and Keyboard shortcuts (?) at the bottom. On the Traffic tab it also has Search (/), Focus, Fit the selection (Shift+2; on when something is selected or focused) and Layers (the five switches and Platform traffic). Focus focuses the selected host, Kubernetes node or namespace, like the panel's Focus this; while a focus is on, it is pressed, and pressing it leaves the focus, like the focus chip, whatever is selected. Hover a tool for its name and key. Esc closes Layers before the details panel. On an empty map the rail keeps Layers (Traffic tab) and Keyboard shortcuts, so switches that emptied the map can be turned back on.
  • Zoom controls at the bottom right: −, the zoom level (click it for 100 %), +, Fit and, on the Traffic tab, Full screen (Exit full screen in full screen, or Esc). Full screen has no key of its own: f fits the map. You can zoom out to half of the whole-map fit and in to 3×.
  • Double-click the background to zoom in there; double-click a card to fit it beside the details panel.
  • Minimap under the zoom controls: the map as plain rectangles, with the part you are looking at outlined. Drag the outline to pan, or click the minimap to jump there. Hide folds it away, and the choice is remembered in this browser. It is hidden when the map is narrower than 640 px.

Once you move the map yourself, updates and resizes leave your view alone. The whole map is fitted again when you press Fit, Shift+1 or f, close the details panel, enter or leave full screen, or when the map is drawn afresh. Opening a selection, a focus or Shift+2 fits what it shows, and the Internet switch re-fits only while you have not moved the map.

Search and shortcuts​

Press / or the tool rail's Search to open the search field beside the rail (Find host, IP, namespace, workload), in full screen too. It suggests up to eight matches as you type: hosts, IP addresses, Kubernetes nodes, namespaces and workloads. Each suggestion shows its kind and context (the IP, or the namespace and node for a workload); matches at the start of a name come first. Use ↑/↓ and Enter to pick. Esc clears what you typed, and a second Esc closes the field; picking, or clicking elsewhere, closes it too. Picking a workload opens its namespace with the workload selected. Entering full screen closes an open field; / opens it again there. With the details panel open, the field and its suggestions stop short of the panel; where the window leaves less than 200 px beside it (a window about 930 px wide or narrower, with the app sidebar open), the field keeps 200 px and is drawn over the panel instead.

Keyboard shortcuts work when you are not typing in a field. The ? tool at the bottom of the tool rail, or the ? key, lists them; off the Traffic tab it lists the map's keys only. The map's keys work while the map has focus (click it, or Tab to it).

KeyDoes
/Search
fFit the map
lTraffic lines
wWorkloads
iInternet
pLive flow
dIdle services
+ / =Zoom in
-Zoom out
Shift+1Fit the whole map
Shift+2Fit the selection or focus
Arrow keysPan
hHand mode on or off
Hold SpaceHand mode while held
?This list
BackspaceBack in the details panel
EscClose what is open over the map (search, Layers, the coverage notes, the Legend list, this list), then the panel, then leave full screen, then leave the focus

Known limitations​

  • A host with no provider tag and no instance metadata (a dedicated server) stays in Other hosts until someone tags it.
  • Conntrack entries are judged against a fixed 50,000, not against the table's size, until agents report it.
  • Trackpad or mouse is a guess. A mouse with a high-resolution wheel can pan where you expected a zoom; the zoom buttons and keys always zoom.
  • Internet paths are not traffic, and the map does not list the internet addresses each host reached.
  • Internet paths get dense when many networks share a gateway: past a few parallel paths their ticks merge.
  • Card text is small on a laptop screen. The whole map is fitted to the canvas, so at a 1440×900 window the smallest card text draws at about 3.7 px (the wider gaps between namespace sub-columns, which routes arrive in, cost about 1%; Proxima's map with every host tagged, so with no Other hosts box, fits larger, at about 4.3 px). Zoom in to read cards (the wheel, a pinch, +, or double-click; see Moving around the map); the map starts at the top of the canvas so none of it is below the fold.
  • Many nodes widen the map. Node rows do not wrap, so a cluster with ten or more workers makes the fitted map smaller and the card text harder to read.
  • A namespace's search context lists short node names ("on w01, w02"), not full names.
  • The gateway address is visible to every reader of the project. A reader who cannot see the gateway host sees the gateway's address but not the host.
  • Routes into one host overlap where they join, so clicking the shared stretch opens whichever is drawn on top. Click a route near where it leaves its card to pick that one, or open the host and use Called by.
  • Lines may cross box and band captions (a lane's or a box's name); they never cross a card.
  • With Internet on, the NAT path can cross the provider caption's network range, for example the 10.10.0.0/16 in the Hetzner Cloud caption.
  • Only the primary provider box spans the columns. Every other provider is drawn as a band below it, but a second provider that holds a Kubernetes cluster box is not banded and can overlap the primary box.
  • A wheel over the minimap zooms the map about the corner of the map hidden under the minimap, not the point the pointer marks on the minimap. Drag or click the minimap instead.
  • Tool rail tooltips need a mouse. They show on hover, not on keyboard focus or touch. Screen readers read each tool's name.
  • The map frame needs Safari 16 or later. It clips the map with overflow: clip, which Safari 15 and older do not support, so there the map's contents are not clipped to the frame.
  • The metrics range resets to Live on reload. It is kept while you stay on the page.
  • Load per core needs the host's core count. Without it (an older agent, or the host record could not be read), the Load row has no per-core figure and no flag.
  • min and max are of the step values. The backend answers one value per step (1 minute for ranges up to 6 hours, 5 minutes for 24 hours), and fills a point's min, max and average with that one value, so a spike shorter than a step can be missed by max and Crossed earlier as well as by avg.
  • Live and 5m judge "now" differently. Live shows a reading up to 5 minutes old as now; a window shows one up to two steps old (2 minutes for 5m), so a host that sent its last reading 3 minutes ago has a now in Live and — in 5m.
  • The Disk row reads the last 15 minutes of mounts, whatever the range, as the host page's disk meters do. A host quiet longer says No host disk in the last 15 min even in a window whose other rows still have figures.
  • The disk history chart is not filtered. The host page's disk meters leave runtime mounts out, but the chart behind Show history still draws every mount the agent reports.
  • Full screen is the Traffic tab's. The other map tabs have no full-screen button.
  • In full screen the browser takes Esc first. It leaves full screen; to close the search field, a popover or the panel there, use its own control first. (Where the browser refuses full screen and the page fills the window instead, Esc closes them in the order above.)
  • On a narrow window, Legend needs the details panel closed. At a window about 900 px wide or narrower, with the panel open, there is no room for the legend's list beside it, so Legend does nothing and says so.
  • Touch is untested. The in-map search, the coverage chip and the Legend list have been tried with a mouse and keyboard only.
  • Cloud metrics lag by up to about one poll interval plus 2 minutes (about 7 minutes at the default 5-minute interval), plus Hetzner's own delay. 5m can briefly say No metrics in this range just before a batch arrives; Live reads 10 minutes, so it does not.
  • Load balancer numbers are the whole load balancer's, not per target, per service or per line. Per-line traffic comes with the agent's network-quality round.
  • A server whose Console host is in an environment you cannot see, or one identified as its host only by the host's name when your hosts:read is scoped to environments, is drawn as a server without an agent. Its section says No metrics from Hetzner yet, because Console does not read Hetzner's metrics for a server that runs an agent. (Matching a server to its host by name needs hosts:read on the whole project, so for an environment-scoped reader that happens even when the host is in their own environment.)
  • After a poller outage longer than an hour, the gap stays: each read goes back at most an hour.
  • Server CPU is Hetzner's figure and is not on the agent's scale. Compare the two only with care.
  • Robot dedicated servers have no metrics: the Robot API has none.
  • A country from the address is only as good as DB-IP Lite. It names a country, never a city or region. Anycast or recently moved address ranges can be placed in the wrong country, which is why the panel says from IP address. The country file ships with Console and is refreshed monthly once a maintainer sets up the geoip:bump schedule; until then it ages, and the backend logs a warning at start-up (country file is over two months old) when the file is more than two months old.
  • A host whose only public address is IPv6 gets no country. A host's addresses are read from its interfaces' IPv4 addresses only, so the address lookup never sees its IPv6 address. Give it a region tag.
  • A host behind NAT with no public address, no region tag and no cloud placement has no location: it sits in Unknown region when its provider has regions.
  • The region catalog is maintained by hand. A provider region Console does not know shows its code with no city or flag until the catalog gains it.
  • A load balancer is placed by its country until the first cloud sync after an upgrade records its location (one Hetzner Cloud sync interval): for that while its panel says Germany · from IP address.
  • A load balancer's panel can name a different region than its box. Its eyebrow shows the balancer's own location, while the map boxes it with the machines on its network (by its own location only when its network has no machine of its provider). A floating IP has no location of its own and is boxed the same way.
  • The eyebrow uses the machine's own spelling of its region. A region box takes its name from one of its machines, so when machines write one region two ways (NBG1 and nbg1), or one of them has no city, a machine's eyebrow can differ from its box's caption.
  • A Kubernetes cluster whose nodes span regions is drawn in its provider box outside every region box.
  • A long region caption can overhang its box by up to about 35 px, into the gap beside it: a cloud region box with no network box inside and a long code (Azure germanywestcentral, Google Cloud australia-southeast1).
  • A routed line can cross a box that is not its own and run along a card's border on its way: boxes are not obstacles to the router, only cards are. It never crosses a card.
  • Logos name a provider; they do not imply endorsement. A provider whose terms forbid it keeps its name and loses its logo.
  • The panel's header row truncates a long place. Very long values end in "…"; hover it to read all of it.