Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Inspect stack runtime state without dropping straight to the node.

​
Prerequisites

  • An existing stack

​
Workflow

1
Use the stack detail page for health, status, services, and recent logs.
2
Use the dedicated logs page for a fuller runtime log stream.
3
Review node assignment, selector tags, and placement choices when behavior differs across nodes.

​
Where to look

  • Stack detail: current status, the list of services, and overall health.
  • Logs: the fuller runtime log stream for the stack and its services.
  • Observability: the operations view for the stack, surfaced alongside the rest of your operational signals.

​
Reading placement

A stack runs on one node at a time. When behavior differs from what you expect, check the node it landed on, its placement mode (manual or least_loaded), and the selector tags that constrained the choice. A stack pinned to an unhealthy node, or a least_loaded stack with no tagged capacity, will show up here first.

​
Runtime status changes

Stack runtime status transitions are emitted as operations events, so a stack that flaps or stops unexpectedly leaves a trail you can follow from the operations surfaces rather than guessing from the node directly.

​
Expected result

You can tie a stack runtime symptom back to logs, service health, and placement.

Deploy a Compose stack

Bring a Compose-defined workload to StackShift with domains, placement, and persistent volumes.

Stack troubleshooting

Common stack-side failures around placement, logs, health, template drift, and restore behavior.

Services view

Track stack-backed services and databases in one place with health, backup posture, and upgrade cues.