> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cyberup24.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Kubernetes Pod Errors

The LARK runs all of its services as containerized applications managed by Kubernetes. The system status page in the admin interface gives you a live view of every pod and its current state. When a pod enters a failed, crash-looping, or stuck state, the analyst tools associated with that service may become unavailable or degrade in functionality. This page explains how to read pod status, what the common error states mean, and what to do about each one.

## Where to see pod status

Open the admin interface in your browser and navigate to the system status page. Each running service appears as a named pod with a current state. A healthy appliance shows all pods in the **Running** state. Any pod in a different state warrants investigation.

## Common pod error states

<AccordionGroup>
  <Accordion title="CrashLoopBackOff">
    A pod in `CrashLoopBackOff` is starting, crashing immediately, and being repeatedly restarted by Kubernetes. The restart interval grows with each attempt.

    **Likely causes:**

    * The service cannot reach a dependency it requires (such as storage or another service)
    * A configuration error introduced by a recent change
    * The pod is out of memory and is being killed on startup

    **What to do:**

    1. Check the pod's logs in the admin interface for a startup error message.
    2. If the error references storage, check storage utilization and offload if near capacity.
    3. If a recent application change was made, consider reverting it.
    4. If the issue does not resolve, escalate to support.
  </Accordion>

  <Accordion title="OOMKilled">
    `OOMKilled` means the pod was killed by the system because it exceeded its memory limit. This typically happens when a service is processing more data than it was sized for, or when too many applications are running simultaneously.

    **What to do:**

    1. Check whether resource contention is occurring — are multiple non-essential applications running?
    2. Disable any optional applications that are not currently needed. See [Application Management](/administration/application-management).
    3. After freeing resources, the affected service will restart automatically. Confirm it reaches a Running state.
  </Accordion>

  <Accordion title="Pending">
    A `Pending` pod has been scheduled but has not started yet. This usually means Kubernetes cannot find sufficient resources to run it, or a dependency the pod requires is not yet available.

    **What to do:**

    1. Check whether the appliance just powered on — some services take a few minutes to start after boot. Wait 3–5 minutes before acting.
    2. If the pod remains Pending for more than 10 minutes after a full boot, check resource utilization and whether other pods are consuming excessive resources.
    3. If a specific dependency (such as a storage service) is itself in a failed state, resolve that issue first.
  </Accordion>

  <Accordion title="Error or ImagePullBackOff">
    An `Error` state or `ImagePullBackOff` can occur if a service's container image is unavailable or was not successfully loaded during an update.

    **What to do:**

    1. Check whether a system update was recently applied or interrupted. If so, attempt to complete or reapply the update through the admin interface. See [System Updates](/maintenance/system-updates).
    2. If the error occurred without a recent update, escalate to support with the pod name and error message.
  </Accordion>
</AccordionGroup>

## Restarting a service

If a pod is in a failed state and you want to attempt a manual restart, use the admin interface to stop and restart the affected service. Do not use the Kubernetes CLI to delete pods unless directed by support — the admin interface provides a safe restart path that accounts for service dependencies.

<Tip>
  After restarting a service, give it 1–2 minutes to fully initialize before concluding whether the restart resolved the issue. Check the system status page again after waiting.
</Tip>

## When to escalate

Escalate to support if:

* A pod remains in `CrashLoopBackOff` after 30 minutes and log review does not reveal a clear cause
* Multiple pods fail simultaneously without an obvious resource or storage cause
* Restarting services through the admin interface does not return them to a Running state

See [When to Escalate](/troubleshooting/escalation-criteria) for what information to gather before contacting support.