GooseOps prevents silent outages and cuts cloud costs with Speedscale

Company

GooseOps is a DevOps and infrastructure consultancy that unburdens startup developers from the tedious minutiae of software automation and operations, allowing them to focus on building the products they love. Teams that work with GooseOps typically achieve faster release cycles, predictable and lower cloud spend, and higher service reliability with fewer outages.

The Challenge: A Kubernetes Migration with Blind Spots

GooseOps was engaged by a major enterprise that was migrating its PHP stack from Docker Swarm to Kubernetes. On paper, the migration looked flawless. But once the workloads were running in Kubernetes, the numbers told a different story: microservices were consuming less than 10% of the node resources provisioned for the cluster. The environment was tremendously overprovisioned, and in production, services were sitting nearly idle.

The DevOps team took an initial pass at the problem by eyeballing metrics and cutting resource requests by a factor of four. The reduction seemed reasonable, but there was no way to know whether the pods would actually survive a real traffic spike or sustained heavy load. Deploying a guess to production was not an option.

We couldn't afford to hit production with this kind of a guess, which led to the obvious next question: why don't we load test our applications?

Steven, Founder at GooseOps

This raised a new challenge. The DevOps engineers tasked with validating the new resource limits had the least knowledge of the application logic and API endpoints. Writing load tests from scratch for applications they did not build or maintain would have taken months—time and effort the team simply could not afford.

Discovering Speedscale

After evaluating a handful of proxy recording tools, the GooseOps team discovered Speedscale—a traffic capture and replay tool purpose-built for Kubernetes. Instead of hand-scripting load tests, Speedscale let the team capture real traffic patterns and replay them as simulated production loads, including both spiky bursts and heavy, prolonged traffic scenarios.

This was the key difference. Engineers who did not write the applications could still produce realistic, meaningful load tests—without reverse-engineering every API endpoint or spending months on test authoring.

Uncovering Hidden Failures

The moment the Speedscale replays began, the problems surfaced. PHP pods started hanging. CPU and memory hit their limits. Every request began timing out. In a live environment, this would have been a gateway timeout—a full service outage invisible to the team until customers started complaining.

The replay revealed a critical misconfiguration: the default PHP-FPM worker setting was far too high for the new resource constraints. After consulting with the original Docker Swarm engineer, the team cut PHP-FPM workers to two per pod and lowered the CPU and RAM limits accordingly.

The replay revealed that the default PHP-FPM worker setting was way too high. In the wild, that would have been a gateway timeout service outage.

Steven, Founder at GooseOps

Mocking External Dependencies for Repeatable Load Tests

With the resource tuning underway, the team hit another problem: the application called an external email sending service during certain user flows. Every time a load test ran, it fired off thousands of real emails. That made repeated testing impractical and risked burning through email service quotas, triggering rate limits, or flooding inboxes with test data.

Using Speedscale's service mocking, the GooseOps team replaced the live email dependency with a mock that returned realistic responses without actually sending anything. This meant the team could run load tests over and over—tuning PHP-FPM workers, adjusting resource limits, and validating autoscaling—without any external side effects. The mock behaved like the real service from the application's perspective, so the test results stayed accurate.

Results

With the corrected PHP-FPM and resource settings in place and external dependencies safely mocked, Speedscale's tests ran cleanly. The outcomes were immediate and measurable:

• Autoscaling validated: Scaling policies worked as expected under realistic load, confirming the new resource limits were production-ready.
• Cloud costs reduced: Node pool costs in both staging and production dropped substantially after eliminating the overprovisioned resources.
• Silent outages prevented: The team proved that a production traffic spike would not trigger a service outage due to misconfigured pod resources.
• Months of test authoring avoided: Speedscale's traffic capture eliminated the need for engineers to manually script load tests for unfamiliar applications.
• External dependencies mocked: The email sending service was replaced with a Speedscale mock, enabling unlimited repeatable load tests with zero side effects.

The enterprise now uses Speedscale for all of its load testing.

Partnership with Speedscale

Beyond the tooling, the GooseOps team found significant value in the Speedscale community and the hands-on support model. The ability to schedule calls to discuss implementation details and feature requests helped accelerate the engagement.

The Speedscale team very quickly made me feel like a member of their team and helped me troubleshoot anything that I brought to them. They even helped identify a problem on my end when it wasn't a Speedscale problem.

Steven, Founder at GooseOps

You can learn more about GooseOps at gooseops.com, on LinkedIn, or on X as @0xGooseOps.