Ctrlk
Sign UpGet a DemoContact Us
For the complete documentation index, see llms.txt. This page is also available as Markdown.

View pod status and logs

View pod-level status, events, and logs for Kubernetes deployment steps directly from the pipeline execution.

This feature is in Beta and requires enablement. View all early access features.

When a Kubernetes deployment fails or hangs, the step logs show whether the step succeeded or failed, but not which pod caused the problem or why. Without pod-level detail, you have to leave Harness and run kubectl against the cluster to find the failing pod, its status, and its logs, often after Kubernetes has already deleted the pod.

Harness collects pod-level diagnostics during the execution and surfaces them in a Pods tab, so you can go from a failed step to a root cause without leaving the pipeline execution.

What you will learn from this topic

Before you begin

  • Applicable step: The step you deploy with must manage pods directly. Go to Applicable steps for the list.

  • Access: This feature is in Beta and requires enablement. Contact Harness Support to enable the CDS_K8S_POD_LOGS feature flag on your account.

  • Minimum delegate version: Delegate version 900xx or later is required to view pod status, events, and logs.

Applicable steps

The Pods tab appears for any step that manages pods directly: Rolling Deployment, Canary Deployment, and Blue/Green Deployment. A stage that runs more than one of these steps shows a separate pod cohort for each step.

Harness captures pod logs and events while the step runs, because Kubernetes typically deletes a pod shortly after the workload reaches a steady state or fails. This lets you open the execution later and still see the pods and their logs, even though the pods no longer exist in the cluster.

Harness retains pod logs and events for seven days after the pipeline execution completes. After that period, the Pods tab no longer shows this data for the execution.

View pods across an execution

At the top of the pipeline execution page, select the Pods tab. This view consolidates pods across every stage and step in the execution.

A banner at the top of the tab shows the collection status, for example Pod data collection complete, along with the time collection finished.

Use the filters above the pod table to narrow the list by stage, step, namespace, phase, or container state, or search for a pod by name. The table lists the following columns for each matching pod.

Column
Description

Pod

The pod name.

Stage / Step

The stage and step that manage the pod.

Phase

The pod phase, for example RUNNING.

Ready

The number of ready containers out of the total, for example 0/1.

Restarts

The number of container restarts.

Diagnostic Reason

The reason Harness surfaces the pod for attention, for example Unhealthy.

Select Download all pod logs to download a zip file with the logs for every pod and container matched by the current filters.

View pods for a step

To see the pods managed by a single step, open the step in the execution view and select the Pods tab, next to Logs, Details, Input, and Output. This view is scoped to the pods that step manages, and shows the same collection banner and pod table as the execution-level view, without the Stage / Step column.

Inspect a pod

Select a pod row to expand it in place. The expanded row has four tabs.

Pods tab on a step, showing the pod table and the Summary tab for a pod

  • Summary: Shows the pod's namespace, node, pod IP, phase, image, workload, conditions, containers, readiness state, restart count, and exit code. Probe and mount failures appear in the Events tab, not in Summary.

  • Status Timeline: Lists the pod's status transitions in chronological order, each with a timestamp and the pod's readiness, startup, restart count, and exit state at that point.

  • Events: Lists the pod's Kubernetes events in chronological order, for example scheduling, container start, and readiness probe failures, each with a timestamp, severity, and message.

  • Logs: Shows the logs for a selected container. Use the container dropdown to switch between containers in the pod, and select Download to download the log for that container.

If a container has restarted, check its previous instance's logs, not only its current logs. Right after a crash and restart, the current instance often has little or no log output yet, while the failure evidence, such as a stack trace or a connection error, is in the previous instance's logs.

Next steps

PreviousDeploy Kubernetes Custom Resources using CRDs
NextKubernetes Tasks

Last updated

Was this helpful?