Operations | Monitoring | ITSM | DevOps | Cloud

Sponsored Post

Your Observability Stack Found the Fire. Congratulations.

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. Thankfully, we have observability.

1,238 API errors in two days, and every response said 200 OK

The query count in our snapshot drawer went blank, and the unit test for that request kept passing. When we went looking in recorded traffic, the API gateway had rejected that request 210 times in a single recording. Every one of those rejections came back as 200 OK. So we searched the rest. We record our own API gateway with Speedscale, and two recording windows from November 3 to 5 (about 38 hours between them) held 1,238 responses with gRPC status INVALID_ARGUMENT. All 1,238 returned HTTP 200.

How to Use Automatic Release Readiness Scorecards

This guide uses Speedscale’s readiness scorecard to compare three builds of a Spring Cloud Gateway service on Kubernetes. It covers a regression that still meets the test’s pass-rate goal, a GET-only retry evaluated under injected dependency failures, and a CI check that requires a Ready verdict. The example uses api-gateway from the banking demo’s readiness-demo branch. The three image tags identify distinct builds.

Automatic Release Readiness Scorecards

Speedscale’s automatic release readiness scorecard grades a completed replay against the release rules in its test configuration. It returns a Ready or Not ready verdict, letter grades for ten metric families, a weighted score and a confidence factor. This feature provides a concrete and automatic baseline for whether new releases are ready for production. The underlying test runs recorded traffic against a build, with dependencies mocked from the recording.

Playwright End-to-End Testing with Recorded API Mocks

Your Playwright test clicks Next page, waits for the item list, and times out. Now you’re digging through a trace to find out whether the page broke or an API call failed. Traditional browser-testing workflows focus on clicks, page state and UI assertions. Those checks tell you whether a user journey works, but investigating a failure also means understanding the APIs behind the page.

gRPC Mocks, Tests and Contract Checks From a .proto

Change one field in a.proto from double to string, and nothing complains. The code compiles, the deploy goes green, and a service still built from the old contract keeps answering with a double. Here’s what Go’s protobuf runtime does when a client on the new contract reads that answer: No error. risk_score comes back empty, and the nine bytes of the double are tucked away as unknown fields.

Test and Mock GraphQL APIs Without Trusting the 200

Replay a GraphQL recording at the server that produced it, and every request comes back 200 OK. Here is one of those 200s, from a Session query whose recorded token has expired: A GraphQL server reports most failures inside a successful HTTP response, so any check that stops at the status code passes this request. And that is the second way GraphQL hides from URL-shaped tooling.

Inside Kraken: Regression Testing With Traffic Replay

A readiness check should make a release safer. During one release validation, ours kept Kraken’s traffic replays stuck in Initializing until they timed out. The operator was asking Kubernetes for EndpointSlices. Its installed permissions did not allow that request. The code needed a real cluster, the generated permissions, and a replay trying to start before that mistake became obvious. Kraken put those pieces together during release validation.

5 Questions to Ask Before the Next Cloud Outage

On October 20, a power failure in one of Google Cloud’s three London zones disrupted Revolut, Lloyds, HSBC and others for hours. One zone failed, errors spread region-wide, and Google warned customers they might not be able to create new workloads to fail over to. Most teams find out how resilient they are during an outage, not before one. These five questions let you find out first.

Load Test One Endpoint, Watch the Rest

What happens to transaction posting when statement traffic gets expensive? That’s the question a bank’s platform team actually needs answered before a busy month-end. It’s also a question most load tests can’t ask, because they turn one dial for the whole recording. Statements get heavier, posting gets heavier, and the average latency across both looks fine right up until customers can’t move money.