Skip to main content
stackdome logs streams output from running application resources. Use it after a resource starts; use stackdome build logs when the image has not finished building.

​
Choose the log source

Read logs across the current stack’s ready resources:
Pass a resource name to isolate one service or job:
To inspect the same resource in a stack outside the current context:
Stack-wide logging includes resources that currently have a ready pod. If none are ready, the command returns an error. Selecting the resource directly is the clearest choice when status already identifies the failing component.

​
Select a window

--tail controls how many existing lines the stream starts with. The default is 100:
--since asks for logs newer than a duration such as 5m or 1h:
You can combine both flags. The server applies the requested filters to the available runtime log stream.

​
Follow new lines

Use --follow to keep the stream open:
The short form is -f. Stop the stream with an interrupt after you have captured the failure or recovery evidence you need. The command writes log lines to stdout. Although the global -o flag is accepted, it does not convert application log payloads into a Stackdome JSON or YAML schema.

​
Runtime logs versus build logs

If a deploy fails before a resource runs, runtime logs may be empty or unavailable. Find the build ID and follow the build-failure decision guide instead.

​
Pair logs with status

Logs explain behavior; status identifies whether Stackdome considers the release and resources healthy. Use both:
After a restart, begin following logs before checking whether the resource returned to a ready state:
Run those commands in separate terminals. See restart a resource for the full verification sequence.