Gitpod Workspace Log Access vs. Deployment Pod Logs Integration Boundary

Direct answer

Gitpod’s built-in UI “Pod Logs” view reads only the primary workspace container. Sidecar container logs are not surfaced there, and Gitpod does not document a standard method to forward them into its log collection pipeline. Retrieve sidecar logs through the Kubernetes API: identify the workspace pod and sidecar container name, then run kubectl logs <pod-name> -c <sidecar-container>. To persist logs across workspace recycling, mount a shared volume into both the primary and sidecar containers and write sidecar logs to a file inside that mount; Gitpod does not automatically forward sidecar logs to external storage.

Likely explanation

A Gitpod workspace pod runs the IDE in the primary container while deployment sidecars run as separate containers in the same pod. Gitpod’s log UI is scoped to the primary container by default, so sidecar stdout and stderr are visible only through cluster tooling, not the Gitpod interface.

Established behavior

• Sidecar logs can be read with kubectl logs <pod-name> -c <sidecar-container-name> when cluster access is available.
• Gitpod does not automatically forward sidecar logs to external storage or include them in the built-in log collection pipeline.
• A shared volume mounted into both containers lets the sidecar write log files that remain after container restarts, subject to volume type and workspace recycle behavior.

Steps for this case

1. List workspace pods and containers: kubectl get pods -n <namespace> -o json, then inspect container names.
2. Read sidecar logs: kubectl logs <workspace-pod> -c <sidecar-container> --timestamps.
3. Follow logs live: kubectl logs -f <workspace-pod> -c <sidecar-container>.
4. Configure a shared volume mount in the workspace setup and direct the sidecar to write logs to a file path inside that mount.
5. After workspace recycling, inspect the mounted volume path to confirm retained log files.

Assumptions and uncertainty

• These steps assume kubectl or cluster API access to the workspace namespace. Without it, sidecar logs are not retrievable directly.
• Gitpod versions before 2023 may use a different pod layout; container names and volume behavior may differ.
• Sidecar containers may lack permission to write to a persistent volume claim; confirm RBAC and security context allow writes.
• It is not confirmed whether Gitpod’s current UI exposes any toggle for sidecar log collection; treat such an option as undocumented until verified in your installation.

Verification

Run kubectl get pods -n <namespace>, identify the workspace pod, then run kubectl logs <pod> -c <sidecar> and confirm output appears. After recycling the workspace, inspect the shared mount path to confirm log files remain.

Missing diagnostic detail: Does your Gitpod deployment provide kubectl or cluster API access to the workspace namespace? This determines whether direct sidecar log retrieval is possible or whether application-level forwarding is required instead.