Skip to content
Brad Stancel

AWS, Kubernetes, and DevOps troubleshooting

I untangle production problems that span layers and turn fragile infrastructure into something documented, reproducible, and recoverable.

“Something in production breaks in a way nobody can explain, and our cloud setup only works because one person remembers how.”

The hardest production problems show up in one place and start somewhere else. An application won't start, and the cause is a storage volume stranded in a different availability zone. A deploy passes every check, and the site still serves a blank page.

I run Ops Insights on Kubernetes in AWS, defined entirely as code, and I've spent years on the operational details that decide whether a system survives its next upgrade: storage placement, networking, secrets, backups, and what happens after a reboot.

How the work goes

  1. Gather evidence first

    Exact errors, logs, versions, and the state before and after. Guessing creates new unknowns.

  2. Find the failing assumption

    I test the narrowest hypothesis at the layer most likely to disprove it, and change as little as possible.

  3. Fix it at the right layer

    Symptoms patched in the wrong place come back. The fix goes where the cause is.

  4. Make it reproducible

    Changes land in code and documentation, so the next person doesn't need to remember anything.

Where I've done this

  • Run Ops Insights on AWS EKS, defined with OpenTofu, Helm, and Argo CD, including version upgrades and a Redis-to-Valkey migration. See more

  • Traced a post-upgrade monitoring outage to a persistent volume and workload in mismatched AWS availability zones. See more

  • Maintain dozens of self-hosted services on Linux and Docker, with ZFS storage and backups verified by restore. See more

Related case studies

Common questions

Can you help in the middle of an outage?

Get in touch and say it's urgent. When I can take it on, the first hour goes to evidence: logs, recent changes, and what's actually failing.

Do we need Kubernetes?

Often not. Plenty of businesses are better served by a couple of well-run Linux servers. I'll recommend the simplest setup that meets your reliability needs.

Our infrastructure isn't in code. Where do we start?

With the pieces that would hurt most to rebuild by hand. We capture those first, then work outward.

Tell me what's slowing the business down.

Describe the problem in plain terms. I read every message myself and reply when there's something I can genuinely help with.

Start a conversation