Logs

A worktree's dev server writes into two places: a live buffer the hub renders, and a rolling file on disk you can read after the app is gone.

In the hub

The Logs button in the hub's toolbar opens a drawer along the bottom of the window for the active worktree. It loads the last 500 lines, then streams new ones as they arrive. Escape closes it.

The button is absent on a worktree hosted by a runner, along with the diff and the changes rail: all three read local process and git state, so on a remote worktree they are left out rather than shown empty. See remote worktrees.

The drawer keeps up to 5,000 lines in view. Behind it, the server holds the same 5,000-line ring per worktree, which is what the drawer is loading from — so opening it after the fact still shows you what happened.

That ring is cleared when you start the dev server yourself, and deliberately not cleared by an automatic retry: after a port conflict the crash output and the eviction note are the explanation for why the restart happened, and throwing them away would leave you with a mysterious second start.

On disk

One combined file, so a problem can be diagnosed without live access:

PathWhat
~/.strado/logs/strado.logServer lifecycle plus a tagged line per dev-server event.
~/.strado/logs/strado.log.1The previous file, kept after a rotation.

It rotates at 5 MB and keeps exactly one old file. STRADO_LOG_DIR moves the directory; the dev profile writes to ~/.strado-dev/logs instead.

Each record is one physical line: an ISO timestamp, a tag, then the message. Dev-server lines are tagged with the worktree's directory name followed by dev, and embedded newlines are collapsed so a multi-line chunk stays greppable as a single record.

Writing to this file never throws. A log that cannot be written is silently skipped rather than allowed to take the server down.

What a failed start looks like

SymptomWhat happened
An error before anything runsThe start command is empty, or a repo with env profiles has no {ENV_FILE} in its command. Nothing was spawned.
The dot turns redThe process exited non-zero. Its exit code is in the dot's tooltip and its output is in the drawer.
[strado] port <n> in use — evicting the listener and retryingThe crash was an EADDRINUSE. Strado cleared that port and started once more; what follows in the log is the second attempt.
[strado] retry failed: …That second attempt could not be made. The message carries the reason.

Both [strado] lines are written into the log as if the dev server had printed them, so the sequence reads in order.

Where to go next