Skip to main content
daily-triage/new-deployment-rollout-crashloop-stale-configmap-mount.md
Daily Triage Briefing

New Deployment Rollout Leaves Pods CrashLooping on a Stale ConfigMap Mount

Impact Summary

A fictional triage exercise: a routine Kubernetes Deployment rollout appears to fail with CrashLoopBackOff, but conflicting evidence points away from the new image and toward a stale ConfigMap volume mount surviving the rollout.

SeveritySEV-3
StatusResolved simulation
PlatformKubernetes & Containers
Incident TypeKubernetes & Containers
Published20 Aug 2026
Technologies Involved
Kubernetes

Simulation Label

Fictional simulation. This exercise is a bounded, invented training scenario for practising operational reasoning. No real organisation, incident, telemetry, credentials or production identifiers are involved or implied.

Operational Summary

Root Cause

An unrelated ConfigMap update added a new field 40 minutes before a routine Deployment rollout; the new image's stricter config schema validator fails fatally on the unrecognised field, while the surviving old pod avoids the fault only because it predates the ConfigMap change and has not remounted its volume.

Detection Method

Evidence-led guided investigation

Current Status

Resolved simulation

Affected Services

Kubernetes

Incident Overview

At 09:12 on a Thursday, the on-call platform engineer for the fictional retailer Northfell Retail receives an alert: the checkout-api Deployment in the checkout namespace has three of four pods in CrashLoopBackOff. The rollout of image tag checkout-api:2.14.0 completed twelve minutes earlier.

The release notes for 2.14.0 describe only a logging library bump. The on-call engineer's first assumption is that the new image is broken.The deployment uses a rolling update strategy with maxUnavailable: 1, so one old pod is still healthy and serving traffic.

Error budgets are close to being consumed if the remaining old pod is replaced or fails.

Investigation Options

Review the available operational moves and select the best immediate action.

A

Roll back the Deployment to image 2.13.4 immediately

B

Inspect the checkout-config ConfigMap and application config schema to confirm whether the new pods are failing to parse a field the application does not yet expect, correlating the ConfigMap update timestamp against the failing pods' start times before changing anything further

C

Scale the Deployment down to zero replicas

D

Restart the kubelet on the affected node

Tags:Kubernetes