Home / BeaverDeck / Docs / Insights Guide / Workload Insights / Container Waiting

Container Waiting

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	`container-waiting`
Insights section	Workload Insights
Alert severity	Warning

When It Reports A Finding

An init or application container is waiting with CrashLoopBackOff, ImagePullBackOff, or ErrImagePull.

Why This Is A Problem

The container cannot start successfully, so the pod may remain unavailable while repeatedly consuming restart or pull attempts.

Recommended Response

For crash loops, inspect current and previous container logs, exit status, command, configuration, and probes.
For image pull failures, verify the image reference, registry reachability, credentials, and imagePullSecrets.
Fix the owning workload and confirm that the replacement container reaches Running and Ready.

Scope And Limitations

Only the listed waiting reasons trigger this check. Other waiting reasons can still require investigation through Pod details and events.

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.