termdeck
Any engine fix: A machine that was working is now offline
A machine that worked yesterday and is grey today has a short list of causes, and one line of the agent log on that machine tells them apart.
is offline. Retrying
Printed by Termdeck.
Diagnosis
A laptop that slept, a reboot where the service was never enabled for boot, or a manual stop. From the other end of a socket that is no longer there, this is indistinguishable from a network failure, which is why the dashboard does not try to guess.
A captive portal, a VPN that took the route, or a firewall that started inspecting outbound WebSockets. The agent keeps dialing and logs a connection problem each time, and that is the difference from a stopped process: a stopped process logs nothing at all.
A self-update that left nothing running is its own state rather than an ordinary offline, and it is worth naming separately because the repair is not the same as a restart.
A machine removed in the dashboard, or a plan that no longer covers it, is refused on the next dial with an HTTP status. That is a loud failure rather than a silent one, and the log carries it.
Check
| Run this | What a good answer looks like |
|---|---|
systemctl --user status termdeck-agent | On Linux: running, stopped or failed, plus the last few log lines. macOS uses launchctl for the same question and Windows the service list. |
tail -n 20 ~/.termdeck/logs/agent.log | A repeating connection problem is a network cause. An HTTP status is an account cause. Nothing since yesterday means the process is not running. |
curl -sS -o /dev/null -w "%{http_code}" https://termdeck.io/healthz | Run on the machine itself. Proves it can reach the service at all, which separates a local network problem from everything else on this list. |
Every command here has been run on a real machine. Termdeck answers the same questions for every machine you have connected, without opening a terminal on any of them.
Fix
A machine that only returns once somebody logs in has the service installed but not enabled.
A sleeping laptop is the most common cause by a distance, and nothing about it needs repairing.
The install command is safe to run again on a machine that already has an agent, and it is the repair rather than a reinstall.
Not this
That mints a new token while the old agent keeps running against a revoked one. A stopped process becomes a machine that can never come back without a second install.
FAQ
Yes, continuously, on a backoff. Fixing the underlying cause is picked up without restarting anything.
Because a stopped process and a dropped network are the same silence from the other end. The log on the machine is where the difference lives.
The transcripts are on that machine and stay there. What stops is reading and running them until it reconnects.
Claude Code, Codex and Grok in one browser console