Home / BeaverDeck / Docs / Insights Guide / Workload Insights / Pod Pending

Pod Pending

BeaverDeck uses this check to identify a specific workload condition that may need operator review.

Permissions: viewing checks requires insights: view. Opening a linked object or logs requires the corresponding resource permission, and the BeaverDeck ServiceAccount must be allowed to read the Kubernetes resources used by the check. Suppressing a finding requires insights: edit and affects all users.

Check type	`pod-pending`
Insights section	Workload Insights
Alert severity	Warning

When It Reports A Finding

A Pod remains in Pending for at least 10 minutes.

Why This Is A Problem

The workload is not running and may be unavailable. Persistent pending pods often reveal insufficient capacity, unsatisfied scheduling constraints, storage failures, or image problems.

Recommended Response

Review the included events such as FailedScheduling, FailedMount, FailedAttachVolume, ErrImagePull, or ImagePullBackOff.
Check resource requests, node affinity, selectors, taints and tolerations, quotas, PVC state, and image pull credentials according to the event reason.
Correct the owning workload or cluster capacity, then verify that a replacement pod schedules.

Scope And Limitations

The ten-minute threshold avoids alerting on normal short scheduling delays. Intentionally suspended or externally controlled workloads may require separate interpretation.

After remediation: refresh Workload Insights and verify the underlying resource or metric. Suppress the finding only when the condition is intentional and its risk is accepted.