Infrastructure Debugging & Incident Response
I find and fix the root cause of broken infra, CrashLoopBackOff, failed deploys, networking black holes, production outages, usually on the first call. You get a working system and a written post-mortem.
Sound familiar?
- ✕Pods stuck in CrashLoopBackOff, ImagePullBackOff, or Pending
- ✕OOMKilled containers and mysterious restarts
- ✕A deploy went out and now prod is throwing 5xx
- ✕DNS, service mesh, or ingress requests vanishing into the void
- ✕The classic "works on staging but not prod" with no explanation
- ✕Latency or error rate spiked and dashboards don't explain it
What you get
- ✓The actual root cause identified and fixed, not the symptom papered over
- ✓System restored to a known-good, stable state
- ✓A written post-mortem with the timeline and the actual cause
- ✓Guardrails (alerts, limits, probes) so it doesn't recur
What this looks like
Most outages have dull causes wearing scary costumes. A CrashLoopBackOff is almost never “Kubernetes is broken.” It’s a missing env var, an over-aggressive probe, a memory limit set too low, or an image that doesn’t actually contain the binary it claims to. My job is to find which dull cause it is this time, fast.
I work the problem top-down: cluster and node events, then workload events, then container logs (current and previous), then resource pressure, networking, and finally what changed recently. I don’t cargo-cult kubectl delete pod until the symptom goes away and call that a fix.
Common scenarios I get called for
- A routine deploy turned into a partial outage and the rollback didn’t fully work.
- Pods are healthy but traffic isn’t reaching them. Usually an ingress, service, or DNS misconfig.
- Intermittent OOMKills under load that only show up at the worst possible time.
- A migration (node upgrade, cluster move, cloud account change) left things half-broken.
- Your dashboards are lying to you and you need someone who can read the system directly.
How an engagement works
- Triage call. You describe the symptom and what changed, and I get access.
- Diagnose. I drive to root cause, narrating as I go so your team learns the trail.
- Stabilize. Restore a known-good state and confirm it holds.
- Post-mortem. A written timeline, the real cause, and the guardrails that keep it from happening again.
Frequently asked questions
How do I fix a pod stuck in CrashLoopBackOff?+
Start with `kubectl describe pod` and `kubectl logs --previous` to see the last crash. The usual causes are a failing liveness probe, a missing config or secret, an OOMKill from a low memory limit, or the container's entrypoint just exiting. I work top-down from events to logs to resource limits until I know which one it is, then I fix the actual cause rather than restarting and hoping.
Can you help during a live production incident?+
Yes. For active outages I jump on a call within hours, pair with your team, and drive to mitigation first, then root cause. Reach out via the contact form or email and mark it urgent.
What do you need from me to start debugging?+
Read access to the cluster or cloud account (or screen-share if access takes time), the rough timeline of when it broke, and what changed recently. That's usually enough to start.
Do you only do Kubernetes?+
No. Most work is Kubernetes (EKS, GKE, AKS, self-managed), but I also debug bare cloud (AWS/GCP), Docker, CI pipelines, networking, and the glue in between.
related work