Operations | Monitoring | ITSM | DevOps | Cloud

A shared Kubernetes cluster rarely belongs to one team. Payments runs checkout in one namespace, search runs search-api in another, and a risk team runs a scorer somewhere else. One Speedscale forwarder captures API traffic for all of them. Redacting that traffic before it leaves the cluster is what makes it safe to use for testing (the background is in The PII Testing Dilemma). Until now, that forwarder ran exactly one DLP rule. Every team that needed a field redacted had to edit the same JSON document.

When I ask an AI agent to change code, I also want it to run the application and test what it changed. Asking it to write some tests is a start. But if it invents the expected responses from the same assumptions it used to write the code, those tests can miss the same mistake. Traffic replay gives the agent something concrete to test against: requests and responses captured from a working application.

In Under the Hood with Go TLS and eBPF, I left socket tracking as an exercise for later. The example used bpf_get_current_pid_tgid() and explicitly excluded concurrent TLS operations. Capturing plaintext was enough for that post. With rustls, later arrived: I could read the HTTP payload perfectly and still attach it to the wrong TCP connection. That’s a frustratingly convincing failure. The request looks right. The response looks right. The application works.

OpenTelemetry graduated from the CNCF in May 2026 as, in the foundation’s own words, the de facto observability standard. The JavaScript API package alone did 1.36 billion downloads in twelve months. That kind of win has a side effect nobody plans for. Once a wire format is everywhere, has a receiver for every source, a transform language, and an agent your platform team already operates, people start putting things on it that have nothing to do with knowing whether a service is healthy.

Handwritten mocks are cheap one at a time. This series built enough of them to show how quickly that stops being true. Nine posts took one package notifier from a function returning "delayed" to a captured response from a real carrier. Along the way, we hand-authored canned successes, failure cases, a spy, a stateful fake, an HTTP server, response fixtures, and contract-drift tests in four languages.

The notifier has returned a message throughout this series, which made testing almost suspiciously easy. Assert on the return value and you are done. Real notifiers do more than build strings: they send them. Once a message goes to an email provider or SMS gateway, the function may return nothing useful. When that change lands, every existing test loses the value it asserted on. This is part 4 of a ten-part series. The code is in Java, Node.js, Go and Python.

Every codebase has a failure path nobody has run. Not through laziness, but because reproducing it requires a backend dependency to misbehave on cue. In the package notifier, the carrier must refuse, stall, or return nonsense at the exact moment the test runs. So the retry logic ships unverified and everyone hopes. The seam from post 2 already gives the test control. A seam is a place where you can change what code does without editing that code.

The spy from post 4 is a sharp tool. Once a test can record every interaction, it is tempting to assert on all of them. The result looks thorough, but it is usually a transcript rather than a useful specification. This post takes a test written that way, makes a change that no customer could possibly notice, and watches the test fail anyway. This is part 5 of a ten-part series. The code is in Java, Node.js, Go and Python.

The dashboards are red, the alerts are firing, and Slack has officially become a war room. Someone has asked, “Anyone else seeing this?” and 14 people have immediately responded with screenshots. Welcome to another day in distributed systems. The recent GitHub outage is a great reminder of how complicated modern applications have become. Services talk to services, infrastructure scales up and down, retries multiply traffic, and dependencies behave in ways nobody expected.

Private cloud and on-premises infrastructure are different. I know this. I used the terms interchangeably anyway because I was trying to compress a pattern into one sentence. That was sloppy, but the underlying pattern still matters. Banks run Kubernetes differently from most other organizations. Not because every bank makes the same choices, but because similar constraints can produce a similar pattern.