rune whoami / status / version

rune whoami

rune whoami
rune whoami -o json

Shows the active context, the server, the configured namespace, the (masked) token, whether the connection works, the server's version, and — if authenticated — the subject ID and attached policies.

Current Context: prod
Server: runed.example.com:7863
Server Version: v0.0.1-dev.40 (51e7782b)
Default Namespace: prod
Token: 29b******364
Status: Authenticated
Subject ID: fba66da0-98de-48b8-b5d3-ae5111900388
Name: alice
Policies: [readwrite]

If Status: Not connected to server, run rune login again or check that the server is reachable. The Server Version line is omitted on older servers that don't expose HealthService.GetServerVersion (added in v0.0.1-dev.38).

rune status

An authoritative, at-a-glance health summary. With no arguments it reports on the whole cluster — like docker info or nomad status — showing cluster health plus a one-line roll-up for every namespace. Narrow to one namespace with -n to get the full per-service table. It surfaces the same statusReason / statusMessage you'd otherwise dig out with rune get service <name>, so failed services explain themselves on the first line.

rune status                         # GLOBAL: cluster + roll-up across all namespaces
rune status -n prod                 # focus one namespace (full per-service table)
rune status --detail                # per-service table for every namespace
rune status --since=30m             # widen the recent-activity window (0 disables)
rune status -w                      # re-render every 2s (Ctrl+C to exit)
rune status -o json                 # structured output for scripts/dashboards

:::note The default scope changed: a bare rune status is now the whole-cluster view (it previously defaulted to the current namespace). -A / --all-namespaces is kept as a back-compat alias for that default; use -n <ns> to focus a single namespace. :::

Default output (global)

The cluster section plus a bounded per-namespace roll-up — no per-service tables (use -n or --detail for those). A cluster-wide recent-activity feed lists WARN/ERR events from the last --since (default 15m).

Rune Status   server=prod.example.com:7863   context=prod
 
Cluster
  Server:     v0.0.1-dev.112
  Runners:    docker=ready, process=ready
  Store:      healthy
  Node:       CPU 38% (8 cores) · Mem 6.2 GiB / 16.0 GiB
  Network:    cidr=10.96.0.0/16, vips=12, capacity 65534
  Registries: 2 (ok 2)
 
NAMESPACE  SERVICES  RUNNING  DEPLOYING  STOPPING  FAILED  PENDING  INSTANCES
dev        8         7        1          0         0       0        12 (1 starting)
prod       12        11       1          0         0       0        28
sys        3         2        0          0         1       0        4 (1 failed)
 
Recent activity
  5m    ERR  prod/instance/payments-2  CrashLoopBackOff   ×2
  9m    ERR  sys/instance/ingress-0    HealthCheckFailure ×4

The Cluster section is sourced only from real signals and every line is best-effort — an unavailable or admin-only probe (network/registries) is omitted, never faked. Runners: docker=unreachable: … is the signal for "the server is up and the store is fine, but Docker is down, so nothing can deploy." Node: is live host pressure (actual CPU%/memory), not declared requests; CPU is omitted on platforms where it can't be sampled (e.g. macOS).

Focused output (-n <ns>)

Rune Status   server=prod.example.com:7863   context=prod
 
Namespace: prod   ·   12 services   ·   28 instances   ·   9 secrets   ·   7 configmaps
  ⊙ Deploying     1
  ✓ Running      11
 
  Instances: Running 27 · Starting 1 · Failed 0 · Stalled 0 · Terminating 0
 
NAME       STATUS     SCALE  IMAGE                 AGE   REASON / MESSAGE
echo       Failed     0/1    …/echo:1.4            3h    ImageUnreachable — auth failed pulling ghcr.io/echo:1.4
landing    Deploying  0/1    …/landing:2.0         1m
api        Running    3/3    …/api:1.4.2           14d
worker     Running    5/5    …/worker:0.9          14d

Rows are ordered so what needs attention floats up: Failed → Stopping → Deploying → Pending → Running. The SCALE column reads ready/desired (the Kubernetes convention), so transitions are obvious:

Structured output

-o json and -o yaml emit a stable, flat and additive shape — safe to bake into dashboards. cluster and recentActivity are top-level and omitted when absent (focused view, non-admin caller, or a quiet cluster):

{
  "server": "prod.example.com:7863",
  "context": "prod",
  "cluster": {
    "serverVersion": "v0.0.1-dev.112",
    "runners": { "docker": "ready", "process": "ready" },
    "store": "healthy",
    "nodeUsage": { "cpuCores": 8, "cpuUsedPercent": 38, "memUsedBytes": 6657199308, "memTotalBytes": 17179869184 },
    "network": { "cidr": "10.96.0.0/16", "vipsAllocated": 12, "capacity": 65534 },
    "registries": { "total": 2, "ok": 2, "failing": 0 }
  },
  "recentActivity": [
    { "namespace": "prod", "kind": "instance", "name": "payments-2", "level": "ERR", "reason": "CrashLoopBackOff", "count": 2, "lastSeen": "5m" }
  ],
  "namespaces": [
    {
      "namespace": "prod",
      "summary": {
        "total": 12, "running": 11, "deploying": 1,
        "stopping": 0, "pending": 0, "failed": 0,
        "instances": 28,
        "instanceStates": { "running": 27, "starting": 1, "failed": 0, "stalled": 0, "terminating": 0 },
        "secrets": 9, "configmaps": 7
      },
      "services": [
        {
          "name": "echo",
          "status": "Failed",
          "image": "ghcr.io/example/echo:1.4",
          "desiredScale": 1,
          "readyInstances": 0,
          "age": "3h",
          "statusReason": "ImageUnreachable",
          "statusMessage": "auth failed pulling ghcr.io/echo:1.4",
          "updatedAt": "2026-05-13T11:21:34Z"
        }
      ]
    }
  ]
}

Flags

Notes

• Glyphs (✓ ⊙ ⏸ ⚠ ·) auto-degrade to ASCII tokens (OK DEPL STOP FAIL PEND) when colors are off (NO_COLOR=1, non-TTY stdout, Windows without ConEmu/WT).
• One ListServices + one ListInstances per namespace — no N+1. The global default keeps each namespace to summary counts, so output size scales with namespace count, not service count.
• Stopping is set server-side whenever the desired scale is below the current instance count; works the same for rune stop and the drain phase of rune restart.
• Service statuses are Running, Deploying, Stopping, Pending, Failed — a service with some unhealthy replicas stays Running/Pending; the ready/desired count is what signals partial readiness.
• Recent activity reads the persisted event log; it's silently empty if the event service is unavailable. Node: / Network: / Registries: are single-node and admin-gated as noted above.

rune version

rune version              # client + server
rune version --client     # client only (skips the server probe)
rune version -o json      # structured output: text | json | yaml
runed --version           # the server's own version subcommand

Client:
  Version:    v0.0.1-dev.40
  Commit:     51e7782b
  BuildTime:  2026-05-13T03:23:51Z
  GoVersion:  go1.22.5
  Platform:   darwin/arm64
Server:
  Version:    v0.0.1-dev.40
  Commit:     51e7782b
  BuildTime:  2026-05-13T03:25:18Z
  GoVersion:  go1.22.5
  Platform:   linux/amd64

The build is tagged with the git commit and build timestamp. If you see -dirty in the version, the binary was built from uncommitted changes.

The server probe uses the unauthenticated HealthService.GetServerVersion RPC (added in v0.0.1-dev.38) so it works before rune login. Against older servers, or without a configured context, you'll see a one-line note instead of the Server: block; use --client to skip the probe entirely.

Combining

A tiny on-call dashboard:

watch -n 5 'rune whoami && echo && rune status'