Schedule icon
Script icon
Docker icon
If icon
SlackIncomingWebhook icon
Log icon
Return icon

Kubernetes Pod CrashLoopBackOff Sentinel

Scans Kubernetes namespaces for pods trapped in CrashLoopBackOff or OOMKilled states, delivering actionable diagnostic cards to SREs on Slack.

Categories
CloudInfrastructure

In containerized cloud environments managed by Kubernetes, pods frequently enter restart loops due to unhandled application exceptions, broken configuration mounts, or out-of-memory terminations (OOMKilled with exit code 137). When a container continuously exits shortly after launching, the kubelet applies an exponential restart backoff delay reaching up to 300 seconds (CrashLoopBackOff).

Left unresolved, crash-looping pods reduce replica capacity, increase traffic pressure on surviving replicas, and eventually trigger cascading latency spikes for customer-facing services. Standard cluster monitoring dashboards can easily obscure single crash-looping pods within large deployments until traffic-routing failures occur.

This blueprint provides an automated reliability sentinel. Running every 15 minutes, it queries the Kubernetes API across designated namespaces, identifies containers exceeding restart thresholds, extracts container termination reasons and exit codes, and dispatches structured triage alerts to Slack.

How it works

  1. Scheduled Audit Trigger: The scheduled_pod_audit trigger (io.kestra.plugin.core.trigger.Schedule) executes every 15 minutes.
  2. Kubernetes API Inspection: The scan_unhealthy_pods task (io.kestra.plugin.scripts.python.Script) executes a containerized Python probe that checks container statuses for CrashLoopBackOff, OOMKilled, and non-zero exit codes.
  3. Condition Evaluation: The check_unhealthy_pods flowable task (io.kestra.plugin.core.flow.If) branches based on whether any failing pods breach the restart threshold.
  4. Slack Alert Dispatch: When crash loops are detected, notify_slack_sre (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a triage card containing the offending pod, namespace, exit code, and immediate diagnosis commands.
  5. Healthy Confirmation: When no workloads are failing, log_healthy_cluster logs compliant status.
  6. Manifest Generation: The export_sentinel_manifest task records an audit manifest for operational records.

Architecture diagram

flowchart TD
    A[Schedule: Every 15 Minutes] --> B[scan_unhealthy_pods: Kubernetes API Probe]
    B --> C{Unhealthy Pods Detected?}
    C -- Yes --> D[notify_slack_sre: Slack Webhook]
    C -- No --> E[log_healthy_cluster: Log]
    D --> F[export_sentinel_manifest: Return JSON]
    E --> F

Use cases

  • Proactive SRE Outage Prevention: Catch failing microservice deployments before pod backoff timeouts cause cascading request timeouts.
  • Automated OOMKilled Detection: Identify memory-constrained Java, Node.js, or Python microservices requiring container memory limit increases.
  • Deployment Rollout Validation: Verify that newly deployed pods in staging or production stabilize without silent restart loops.

Inputs

Name Type Default Description
target_namespaces STRING default,production Comma-separated list of Kubernetes namespaces to inspect.
max_restart_threshold INT 3 Minimum restart count before flagging a container as crash-looping.
slack_channel STRING #sre-alerts Slack channel destination for operational failure notifications.

Expected outputs

  • {{ outputs.scan_unhealthy_pods.vars.has_unhealthy_pods }}: Boolean flag indicating if failing pods were detected.
  • {{ outputs.scan_unhealthy_pods.vars.unhealthy_count }}: Total number of pods breaching restart thresholds.
  • {{ outputs.scan_unhealthy_pods.vars.top_pod_name }}: Name of the most critical failing pod.
  • {{ outputs.scan_unhealthy_pods.vars.top_termination_reason }}: Primary termination cause (OOMKilled, Error, etc.).
  • {{ outputs.scan_unhealthy_pods.outputFiles['unhealthy_pods_report.json'] }}: Structured JSON report.

Prerequisites

  • Kubernetes cluster connectivity with RBAC permissions to read Pod resources in target namespaces (pods: get, list).
  • Incoming Webhook URL configured for your SRE Slack channel.

Secrets

  • SLACK_WEBHOOK_URL: Slack Incoming Webhook endpoint URL.

Quick start

  1. Configure SLACK_WEBHOOK_URL in your Kestra namespace secrets.
  2. Import this flow YAML into your Kestra workspace.
  3. Update target_namespaces to include your production namespaces.
  4. Click Execute in the UI to run an immediate cluster workload audit.

Common pitfalls and troubleshooting

  • RBAC Permissions: Ensure the Kestra service account has get and list permissions on pods across all target namespaces; missing permissions result in HTTP 403 Forbidden errors.
  • Job Pods vs Service Pods: Completed batch Jobs often exit with status Completed (exit code 0). The sentinel specifically inspects restartCount and abnormal termination reasons to prevent false alarms on one-off batch runs.

How to extend

  • Add io.kestra.plugin.kubernetes.kubectl.Apply to automatically scale down failing deployments or rollback to previous revisions.
  • Fetch previous container logs via kubectl logs --previous and attach the last 20 log lines to the Slack incident alert card.
  • Integrate with PagerDuty for high-priority on-call paging when critical customer-facing pods fail.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.