System (#/system, Ctrl+Alt+Y) answers "is anything about to go wrong":

• CPU and load, against the number of cores.
• Memory, with what is cached rather than lost, and swap — the number that actually matters, because a machine swapping under pressure is a machine about to crawl.
• GPUs (NVIDIA, through nvidia-smi), memory and temperature, when there are any.
• Every disk holding a configured root (each device once), with a plain reading of how close each is to full.
• Uptime, and at the top the reading in the most trouble ("busiest: memory").

Amber and red are fixed thresholds: memory 75 % / 90 %, swap 25 % / 60 %, disk 80 % / 92 %, CPU 70 % / 90 %, GPU 80 % / 95 %. Swap shows only when there is some. It refreshes every 4 s by default (4 s, 15 s, 1 min, 5 min or manual, with Read it again now). The routes: /api/system, /api/ports, /api/labels, /api/network — see API reference.

• The largest processes, each with its whole command line — and a label of your own, for the ones you would otherwise have to work out again every time.

The worst of those numbers again, as a small icon in the header — not only on this screen (below 560 px wide, only while something is amber or red). The point of it is that noticing a disk filling up should not depend on remembering to come back and look: it is read on its own clock, every 30 seconds, whether or not this screen is open, and paused while the tab is in the background.

It is quiet on purpose. A fine reading is a plain icon, the same as any other in the header — nothing pinned there permanently should shout, or it stops being noticed within a day. It picks up amber or red only once the worst number actually crosses into warning or critical, the same thresholds and the same two words this screen uses for its own hero number, and a click opens this screen.

At the top, because "which address do I type" is the question people arrive with:

• the hostname, and the user you would ssh in as
• every address it answers on, the one on the default route first and marked as such. Found by asking the kernel which source it would use for a route to nowhere — no packet is sent, it works with the cable out, and it is right where gethostbyname(gethostname()) says 127.0.1.1 and means nothing
• a tunnel to it, always shown, because a firewall is invisible from here. Argus can sit behind the same firewall as anything it watches, on a box with nothing routed to it at all — the same ssh line the ports section builds for a proxied port, but for Argus's own address this time: ssh -N -L 8080:127.0.0.1:8080 you@this-machine (with your port: 8080 by default, 8090 in Docker), run on the machine you're actually sitting at. Under it, the URL to open once that tunnel is up, already carrying the token — paste it as it stands, on the machine that ran the command, not on this one
• your own address, as the socket saw it. Behind a reverse proxy that is the proxy, so what the proxy claims about you is shown beside it and separately: one is a fact, the other is a header
• what the world sees, only if you press it. The button names the service before you press, because asking somebody what your address is is telling them. ask_outside: false in the config removes the offer altogether

Every value has a copy button. All of them exist to be typed somewhere else, and an address read off a screen and retyped is an address with a digit wrong in it.

The six biggest by memory. java, 2.2 GB is where the question starts — which java, doing what, and can it go — so under each name is its full command line, and hovering shows the pid.

Write down what it is. The pencil on a row, here or on a listening port below, puts a label on that process: "cgDist rerun, Listeria batch — ask before killing". The label takes the name's place, in the accent colour, with the machine's own name and command underneath. An empty label clears it; one line, at most 80 characters.

A label belongs to one process, not to a number. Process ids are recycled, and the note written on pid 4242 must not turn up on whatever the kernel hands 4242 to next week — so a label is kept against the pid and the moment that process started, and it goes when the process ends (it is written out of the file too, the next time anything reads it). It is kept on the server, in labels.json beside the config, so a note made on the phone is there on the desk. Labels are yours: an agent's token can neither read nor write them.

Every port with something listening, and what is holding it — with the same pencil as the processes above, since python3 on 8888 is the same question. A service bound to 127.0.0.1 is unreachable from a phone by design — that is what binding to loopback means.

With --allow-proxy, Argus will stand in front of one: open the port from this screen and it is served under /proxy/<port>/, inside a window or a tab. A loopback URL clicked in a terminal does the same thing on the spot.

Nothing is proxied unless the server was started with --allow-proxy and that particular port was opened by hand. A port bound to loopback was bound there on purpose.

Opening one is remembered, in a small file beside the config, so a restart is not the same as closing every port that was open before it — a job left running for days should not need somebody to come back and press Reach it again each time the machine is rebooted. --allow-proxy still gates all of it on every request, on every restart: losing that flag is exactly as it should be, and this only restores a decision that was already made while it was on.

Every port has a twist that opens three lines under it, whether or not it has been opened yet — because the way to see the address should not be to open the port.

Your credentials stop at Argus. The token is taken out of the query before the request is passed on, the cookie and the Authorization header are dropped (all cookies — so a proxied service that keeps you signed in with its own cookie will not stay signed in through Argus; use the ssh line for that one), and the Referer is rewritten to the service's own address without its query — that last one because a page opened at /proxy/11000/?token=… puts the whole address, token and all, into the referer of every request it makes, and a referer is not hop-by-hop. It would have gone into the service's access log.

What the service does get is a Host of 127.0.0.1:<port>, so it cannot tell it is being stood in front of, and — if it answers HTML — a <base> tag so its relative links work.

Absolute paths are handled too. A <base> cannot fix /static/app.js or /api/dashboard: those ask the root of Argus. The referer says which proxied page asked, so they are sent home — including paths Argus itself has a file for, and including the ones under /api/ that Argus would otherwise refuse before looking. Without that a dashboard renders as bare markup with no script, no style and no data, which is the shape this bug arrives in.

The box above the list takes a port number, whether or not anything is listening on it yet — a service that has not started, or one the scan did not see. It shows up in the list either way, marked as opened by hand, so you can close it again.

The case this is really for. A tool running on the server starts a browser login whose callback is http://localhost:1455/…. You do the login on your own laptop, where localhost is your laptop, and the callback lands on nothing: This site can't be reached. The port forwarding is not broken — nothing was ever forwarded to your laptop, and nothing can be: Argus is a page in a browser, not an SSH client.

What Argus can do is stand in front of the port on its own machine. Copy the dead URL out of the address bar, paste it into the same box, and it is forwarded — path and query intact — to the port it was always meant for:

http://localhost:1455/auth/callback?code=…&state=…
        ↓
https://your-server/proxy/1455/auth/callback?code=…&state=…

The listener waiting inside the server gets its callback and the login completes. Doing it by hand is the same edit, so nothing here is magic — it just saves getting the prefix wrong while a one-time code expires.

Argus's own credentials stop at the proxy: neither the token in the query nor the Authorization header reaches the service behind it, so a callback URL in somebody's log does not carry your token with it.

VS Code forwards a port so well that localhost:1455 on your laptop simply works. It can do that because it has a piece running on your laptop: the client opens a listening socket on your own 127.0.0.1:1455 and tunnels it to the remote one. Something really is answering there.

A web page cannot do this. A browser does not let a page listen on a TCP port of the machine showing it — nobody gets to, and rightly so. Standing in front of the port from the inside is the only move Argus has.

If you want the literal localhost behaviour, the program VS Code uses under the hood is already on your machine:

ssh -L 1455:127.0.0.1:1455 you@server

While that session is open, the dead callback URL works verbatim, with nothing to rewrite. The proxy is the answer when you have only a browser — a phone, someone else's laptop — and the price is that the address changes.

A general proxy. It forwards HTTP to 127.0.0.1:<port> on the machine Argus runs on, one port at a time, for a browser that is already authenticated to Argus. It is not a SOCKS proxy and cannot be one: SOCKS is a TCP listener that a client — a browser, Spotify — is pointed at in its own settings, and none of those clients speak to Argus. For that, ssh -D 1080 user@server gives you a SOCKS5 proxy on your own machine in one command, authenticated by your SSH key, with nothing extra to run on the server.