GoogleContainerTools/skaffold · error

STATUSCHECK_RUN_CONTAINER_ERR

STATUSCHECK_RUN_CONTAINER_ERR

Error message

container %s in error: %s

What it means

Skaffold's health-check validator inspects a pod container stuck in a Waiting state and maps known Kubernetes waiting reasons to status codes. When the waiting reason is a run-container error (e.g. OCI runtime failure) and its message matches runContainerRe, it reports STATUSCHECK_RUN_CONTAINER_ERR with the trimmed runtime message. This tells you the container image itself failed to start, not that scheduling or pulling failed.

Source

Thrown at pkg/diag/validator/validator.go:375

func extractErrorMessageFromWaitingContainerStatus(po *v1.Pod, c v1.ContainerStatus) (proto.StatusCode, []string, error) {
	// Extract meaning full error out of container statuses.
	switch c.State.Waiting.Reason {
	case podInitializing:
		// container is waiting to run. This could be because one of the init containers is
		// still not completed
		return proto.StatusCode_STATUSCHECK_POD_INITIALIZING, nil, nil
	case containerCreating:
		return proto.StatusCode_STATUSCHECK_CONTAINER_CREATING, nil, fmt.Errorf("creating container %s", c.Name)
	case crashLoopBackOff:
		// TODO, in case of container restarting, return the original failure reason due to which container failed.
		sc, l := getPodLogs(po, c.Name, proto.StatusCode_STATUSCHECK_CONTAINER_RESTARTING)
		return sc, l, fmt.Errorf("container %s is backing off waiting to restart", c.Name)
	case ImagePullErr, ImagePullBackOff, ErrImagePullBackOff:
		return proto.StatusCode_STATUSCHECK_IMAGE_PULL_ERR, nil, fmt.Errorf("container %s is waiting to start: %s can't be pulled", c.Name, c.Image)
	case runContainerError:
		match := runContainerRe.FindStringSubmatch(c.State.Waiting.Message)
		if len(match) != 0 {
			return proto.StatusCode_STATUSCHECK_RUN_CONTAINER_ERR, nil, fmt.Errorf("container %s in error: %s", c.Name, trimSpace(match[3]))
		}
	}
	log.Entry(context.TODO()).Debugf("Unknown waiting reason for container %q: %v", c.Name, c.State)
	return proto.StatusCode_STATUSCHECK_CONTAINER_WAITING_UNKNOWN, nil, fmt.Errorf("container %s in error: %v", c.Name, c.State.Waiting)
}

func newPodStatus(n string, ns string, p string) *podStatus {
	return &podStatus{
		name:      n,
		namespace: ns,
		phase:     p,
		ae: proto.ActionableErr{
			ErrCode: proto.StatusCode_STATUSCHECK_SUCCESS,
		},
	}
}

func trimSpace(msg string) string {

View on GitHub (pinned to a1189de023)

Solutions

  1. Run the image locally (docker run <image>) to reproduce the runtime failure and fix the entrypoint/command or missing runtime dependencies.
  2. Verify the image architecture matches the cluster nodes (docker inspect <image> | grep Architecture; build with --platform if needed).
  3. Check the full State.Waiting.Message via kubectl describe pod <pod> for the underlying OCI runtime error and correct the container spec (env, volumes, securityContext).

Example fix

// before: bad entrypoint in verify action config
cmd: ["/app/start.sh"] // file not in image -> run-container error
// after
cmd: ["/bin/sh", "-c", "/app/start.sh"] // ensure script exists in image and is executable
Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-check the image runs before submitting to the cluster
docker run --rm --entrypoint <image> -- <smoke-cmd> || echo "image runtime broken"

Try / catch

try {
  await skaffold.verify(...);
} catch (e) {
  if (String(e).includes('STATUSCHECK_RUN_CONTAINER_ERR') || /container .* in error/.test(String(e))) {
    // pull container name from message and inspect locally
    const name = String(e).match(/container (\S+) in error/)?.[1];
    console.error(`Runtime failure in ${name}; test the image with docker run`);
  }
  throw e;
}

Prevention

When it happens

Trigger: A container's State.Waiting.Reason is ErrRunContainer / CrashLoopBackOff-style runtime error (from getContainerStatus -> extractErrorMessageFromWaitingContainerStatus during a skaffold verify or apply health check) and State.Waiting.Message matches the runtime error regex.

Common situations: Bad entrypoint or command in the image manifest; incompatible architecture image (arm64 vs amd64); missing shared libraries at runtime; seccomp/capability restrictions on the cluster rejecting the container start.

Related errors


AI-assisted analysis of GoogleContainerTools/skaffold@a1189de023 (2026-09-05). Data as JSON: /api/errors/d39acf710735d03d. Report an issue: GitHub.