Container start

A real percentage while a container starts, and "Running" only when it is ready to use. Both come from measured steps, not from a timer.

Running and 100 % come together, and only after the readiness check.

Diagram as text

You press Start. The container shows Starting and 0 percent.
ZeroLog plans the start, checks the image, prepares the network and mounts the workspace. Each finished step moves the number.
The machine is created and booted. For a VM this is the longest step.
The readiness check runs a command in the machine, checks the network gateway, the inner sandbox (VM with gVisor) and the file list.
Only now the container shows Running and 100 percent. The terminal and the Files view open.
If a step fails, the view names the step and the reason, and Try again starts it again. A machine that failed the check is stopped.

The steps: planning the start, bringing the workspace back from network storage (only if it was moved there), checking the image, preparing the network, mounting the workspace, creating the machine, booting it, starting the inner sandbox (only for the VM with gVisor class), checking network access, and a readiness check. The bar shows the step you are in and its percentage.
Where the number comes from: every finished step counts with its weight. The step in progress adds a part of its own weight: bytes unpacked while the workspace comes back, probe attempts during the readiness check, or elapsed time against the usual time for that step. The number never goes past the weight of the current step and never reaches 100 before the container runs.
Taking longer than usual: if a step takes three times its usual time, the number stops and the view says so. It does not creep forward to look busy.
Running means ready: a command runs inside the machine, the sandbox network has a gateway (so the terminal can connect), and, for the VM with gVisor class, the inner sandbox answers. The file list is tried with a short deadline. Only after that does the container show Running and 100 %. Until then the terminal answers with "still starting" instead of an error, and the Files view opens when the container runs.
If a step fails: the view names the step and the reason, the container goes back to the state it was in, and Try again starts it again. A machine that booted but failed the readiness check is stopped, so it never shows Running next to an error.
The agent runtime (used by Tailscale and by agents in your chats) is its own phase after the start. It is not a condition for Running; opening Tailscale or the terminal waits for the same start instead of building a second one.
Measured, not guessed: each step's duration is stored. The weights start from one cold-start measurement and are pulled from the medians as data comes in.
For API clients: send the header X-ZL-Start: async with POST /api/containers/:id/resume to get 202 and poll GET /api/containers/:id/wecken. The wecken object carries phase, phase_label, prozent, schritt, fehler and fehler_phase. Without the header, the call waits and answers 200 as before, and wecken is included.

Pausing and storage are described under Containers. The Tailscale connection is under Tailscale in a container.