Troubleshooting

Start with the daemon, then check the workspace connection or deployment operation.

Is the daemon available?

systemctl status readylabd --no-pager
journalctl -u readylabd -n 100 --no-pager
readylab health

Run the CLI with the daemon owner’s permissions and the correct socket path. The installed service uses /run/readylab/readylabd.sock. A custom installation may use another configured runtime directory.

Can the host run workspaces?

Check that Linux can access KVM and that the binary matches your x86_64 or ARM64 architecture. Ubuntu- and Debian-based Linux distributions are supported. A remote virtual machine needs nested virtualization enabled by its provider.

Can’t connect to a workspace?

Check that the workspace is freshly Ready, the node SSH identity is trusted and your workspace public key was supplied at creation. Use the node’s jump-host route when the workspace address is private. A fingerprint mismatch needs investigation, not disabled host-key checks.

Did a build fail?

readylab deployment logs <deployment-uuid> --tail 100
readylab operation <operation-uuid>

Confirm that the full revision exists in the Git remote, the repository contains the selected Dockerfile and build context, and the node’s deployment backend is enabled. Operation errors and application logs describe different stages.

An uncertain command result

Keep the command’s printed request key. Retry the same command and body with that --request-id to resolve an uncertain response. Do not issue another create request with a new key just because the first response was lost.