Troubleshooting

"No answer from moonwayd"

Settings → Daemon (moonwayd) is the ground truth: it shows whether the daemon is answering, its version, and the sync state of each watched cluster. If it isn't answering, quitting and reopening the app is the fix in almost every case — the app supervises its own daemon and restarts a crashed one automatically, so a persistent "no answer" usually means something is sitting on the port.

lsof -i :5171

The daemon binds 127.0.0.1:5171 by default. If another process owns the port, free it — the login-item daemon and the app negotiate the same port and token through ~/.moonway, so a foreign occupant is the case worth investigating.

Metrics are empty

Metrics come from each node's stats summary through the API server proxy — no metrics-server involved — which requires get on nodes/proxy. If the Metrics tab and the CPU/Memory columns stay blank while everything else works, that's the permission your user is missing. Some managed clusters restrict the kubelet proxy path; the rest of Moonway is unaffected.

A context is missing

Moonway lists the contexts your kubeconfig defines. If one you expect isn't offered, check what kubectl config get-contexts says from the same shell you launch Moonway from — merged kubeconfigs and per-shell KUBECONFIG overrides are almost always the answer.

Where the logs are

For a bug report, the daemon's log is the artifact that helps:

Logs are size-capped and rotated (two generations), and they contain cluster object names — skim before you share if that matters in your environment.

Still stuck? support@moonway.io — a human reads it, and the log plus your platform and version is everything we need.