> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Logs and shell

> Watch a deployment's output and open a terminal into a running container.

Every service page carries the tabs you need to watch it run. Under **Monitor** there are
**Logs**, **Timeline** and **Metrics**; under **Manage** are the controls that apply to that
kind of service, including **Shell**.

A static site has no pod, so it has no Shell, Metrics, Compute, Scaling, Disks or Sleep tab.
On a plan without the capability, Shell, Scaling and Disks appear with a lock.

## Logs

Every line your containers write to stdout and stderr is captured and kept for 30 days.
slipway narrates its own deploy steps into the same stream, so the log carries the whole
story rather than only your app's output.

The Logs tab is where a deploy is watched. Every deploy action lands there, the phase
ladder in the service header walks Build, Deploy and Live, and the log below streams the
run as it happens. Opening a past run from the service's Events opens the same tab pinned
to that run, with a notice above the log and the run's own event row, so an older build's
replay is never mistaken for live output.

![The service's Logs tab](https://mintcdn.com/slipway/XQ-cfaZA6zvMJ_Pi/images/deployments/detail-logs.png?fit=max\&auto=format\&n=XQ-cfaZA6zvMJ_Pi\&q=85\&s=6cf759c98d36e6a1d6c89287718c9b5b)

Three kinds of line are interleaved, each tagged by source.

| Source | What it is |
| - | - |
| slipway steps | The platform's narration: fetching the spec, resolving secrets, building, deploying, waiting for readiness, and the verdict. |
| Build output | Clone and image-build output, tagged by service. |
| Container output | Your services' stdout and stderr once running, tagged by service. |

Filter by phase to jump to the stage you care about.

| Phase | Covers |
| - | - |
| Build | Image builds: clone and build output plus the building narration. |
| Deploy | Resolving secrets, applying workloads, preparing disks, waiting for readiness, exposing URLs, and the surfaced pod events. |
| Run | Your services' own output once running. |

You can also narrow to a single service, hide slipway's narration when you want only your
containers' output, and search with optional regex and case-sensitive toggles. Copy the
visible lines, or download the full buffer as a `.log` file.

Opening the tab mid-deploy gives you the last few minutes immediately.

For every lifecycle status and event kind, see
[Statuses and events](/reference/statuses-and-events).

## Timeline

The **Timeline** tab draws every state the deployment's services have been in on one
horizontal time axis: one row per service, grouped by repository, with a project-level band
on top.

Coloured spans show queued, building (with cache hits visible), deploying, healthy, sleeping
and waking, and any crashed stretches. Markers flag failures, cancellations, cutover and
teardown. Hover a span for its duration, the commit and trigger behind it, and why it ended.

Scroll to zoom, drag to pan, double-click to reset, and switch the range between the last
hour, day, week, or the whole life of the project.

Unlike logs and metrics, the timeline is built from durable deploy records, so it keeps the
full history. A crash loop from two months ago is still there.

## Shell

When a service is healthy, the **Shell** tab opens an interactive terminal into its
container, with no `kubectl` and no kubeconfig.

The **Service** dropdown switches which container you are attached to, and **Reconnect**
starts a fresh session on the same one. **New tab** opens a dedicated terminal window
alongside your logs.

It is a real PTY, so arrow keys, tab completion, full-screen programs such as `top` and
`vim`, colour and resize all work.

| Constraint | Detail |
| - | - |
| Healthy only | There is no container to attach to before `healthy`, and none after a terminal state. |
| Which shell | slipway uses the first of `/bin/sh`, `/bin/bash` or `/bin/ash` that exists in the image. A fully distroless image has no shell to attach to. |
| Ephemeral | Anything you install lives in that container's writable layer and is gone on the next restart. |
| Permissions | Developer role or higher, and the Shell capability on your plan. |

Every session is recorded in the organization's activity log with the user, service and
deployment.

From the CLI, `slipway exec` and `slipway ssh` reach the same containers. See
[the CLI](/integrations/cli). To reach the same shell from a standard SSH client — for
one-off commands, `scp`, or editor remote-SSH — see [SSH access](/observability/ssh).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.