<!--This issue template can be used as a great starting point for feature requests. Learn more about the process: https://handbook.gitlab.com/handbook/product/product-management/#customer-feature-requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md).--> ### Release notes You can use the dashboard for Kubernetes to monitor your deployed applications. Until now, pods with container errors like CrashLoopBackOff or ImagePullBackOff were only shown as "Pending" or "Running," making it difficult to identify problematic deployments without using kubectl. GitLab now properly displays these error states in the UI, showing the specific container error status. This improvement makes the Kubernetes dashboard more consistent with kubectl output and helps you quickly identify and troubleshoot failing pods without leaving the GitLab interface. ### Proposal Currently, our Kubernetes dashboard shows pods with CrashLoopBackOff and ImagePullBackOff states as "Running" or "Pending," creating inconsistency between our UI and what users see with kubectl. This leads to confusion as environments appear healthy in the dashboard when they're actually failing. This issue proposes enhancing our pod status visualization to correctly identify and display CrashLoopBackOff, ErrImagePull, ImagePullBackOff, and other error states in the UI, matching what users would see in kubectl. ### Technical details: The issue stems from relying solely on the pod's metadata.status.conditions object and metadata.status.phase, which reports CrashLoopBackOff and ImagePullBackOff as "Pending" We need to also check the `containerStatuses[].state` field to detect these error states Add appropriate styling (badge type danger) to visually distinguish these failure states. The status should be updated both in the pods table and in the pod details drawer. ### Expected behavior: * Pods in states like `CrashLoopBackOff`, `ErrImagePull`, or `ImagePullBackOff` should be clearly labeled as such * Visual indicators (danger badges) should make it immediately obvious that these pods are in an error state * Status labels should match what users see when using kubectl * The status text should provide actionable information for troubleshooting ### Design proposal | Current | Proposal | |---------|----------| |  |  | |  |  | ### ### Intended users * [Priyanka (Platform Engineer)](https://handbook.gitlab.com/handbook/product/personas/#priyanka-platform-engineer) * [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator) * [Allison (Application Ops)](https://handbook.gitlab.com/handbook/product/personas/#allison-application-ops) * [Ingrid (Infrastructure Operator)](https://handbook.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) ### Feature Usage Metrics <!--How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Explore (../../doc/development/internal_analytics/internal_event_instrumentation/quick_start.md) for a guide.--> ### Does this feature require an audit event? <!--- Checkout these docs to know more https://docs.gitlab.com/ee/development/audit_event_guide/#what-are-audit-events https://docs.gitlab.com/administration/compliance/audit_event_reports/ ---> <!--Label reminders Make sure to add the appropriate labels for the product stage and/or group (e.g ~"devops::plan") if known and add a comment tagging the appropriate Product Manager. Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ Examples: /label ~group:: ~section:: ~Category: /label ~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate"-->