> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/view-pod-status-and-logs.md). # View pod status and logs View pod-level status, events, and logs for Kubernetes deployment steps directly from the pipeline execution. {% hint style="info" %} This feature is in Beta[^1] and requires enablement. [View all early access features.](/release-notes/features.md) {% @harness-feature-flag-access/request-feature-flag-access module="continuous-delivery" pagePath="continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/view-pod-status-and-logs" featureFlags="%5B%7B%22name%22%3A%22View%20pod%20status%20and%20logs%22%2C%22key%22%3A%22CDS\_K8S\_POD\_LOGS%22%2C%22status%22%3A%22BETA%22%2C%22description%22%3A%22Shows%20pod-level%20status%2C%20events%2C%20and%20logs%20for%20Kubernetes%20deployment%20steps%20in%20a%20dedicated%20Pods%20tab%2C%20at%20both%20the%20execution%20level%20and%20the%20step%20level.%22%7D%5D" %} {% endhint %} 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 * How to view [pod status across an entire pipeline execution](#view-pods-across-an-execution), across every stage and step. * How to view [pod status for a single step](#view-pods-for-a-step). * How to [inspect a pod's summary, status timeline, events, and logs](#inspect-a-pod). * How to download pod logs, from either the execution-level or the step-level **Pods** tab. *** ## Before you begin * **Applicable step**: The step you deploy with must manage pods directly. Go to [Applicable steps](#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](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5c964fc1b14c49d1ee07eb7aaec48e4e7ebacfec%2Fpipeline-pod-tab.png?alt=media) * **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. {% hint style="info" %} 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. {% endhint %} *** ## Next steps * [Create a Kubernetes Rolling deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-rolling-deployment.md): Configure a Rolling Deployment step, one of the applicable steps for this feature. * [Create a Kubernetes Canary Deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-canary-deployment.md): Configure a Canary Deployment step, one of the applicable steps for this feature. * [Create a Kubernetes Blue Green deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-blue-green-deployment.md): Configure a Blue/Green Deployment step, one of the applicable steps for this feature. {% @harness-feedback/feedback %} [^1]: Beta features are feature-complete but still being validated. Available on request.