Atlanta, GA, USA
2020
  |  By Matt LeRay
The first number from my local PostgreSQL 16 test was roughly 1,600 statements per second. It looked impressive. It was also the least useful result in the run. The useful part was the workload. It came from queries the demo app had actually sent: the same prepared statements, parameters, reads and writes. A synthetic benchmark tells you how PostgreSQL handles a synthetic workload. It does not tell you whether your migration just broke the UPDATE your app depends on.
  |  By Alan Mon
Remember when “going shopping” meant getting in the car? This fall, filling the tank feels like applying for a small loan. U.S. regular gasoline averaged about $4.48 a gallon for the week of September 21, 2026. A round trip to the store starts competing with free shipping. And free shipping never needs a parking spot. That doesn’t tell us how many shoppers will move online this holiday season.
  |  By Ken Ahrens
Synthetic monitoring has been a critical part of application reliability for years. It gives engineering and operations teams a way to proactively test applications, APIs, and critical customer journeys before users encounter problems. But there is a fundamental limitation with the traditional approach: Someone has to create the tests. As applications become more distributed and customer journeys become more complex, organizations can end up maintaining hundreds or even thousands of synthetic scripts. Every new feature, API, dependency, or change to a customer journey can require another update.
  |  By Matt LeRay
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.
  |  By Ken Ahrens
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.
  |  By Shaun Duncan
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.
  |  By Matt LeRay
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.
  |  By Matt LeRay
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.
  |  By Matt LeRay
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.
  |  By Matt LeRay
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.
  |  By Speedscale
A breakdown of the three potential ways software engineers will interact with AI coding assistants, ranging from local desktop setups to fully automated software delivery factories. Learn more: speedscale.com.
  |  By Speedscale
While AI coding tools dramatically slash development time, they are quietly inflating testing and maintenance burdens because teams no longer fully understand their codebase. Discover how leading engineering teams are shifting focus to testing and context packages to eliminate bottlenecks and unlock true AI efficiency.
  |  By Speedscale
AI agents can write tests, but those tests can repeat the same assumptions that led to the code. In this walkthrough, I use Cursor and proxymock to replay real application traffic against a local Go app, compare requests and responses, and validate code changes with real data.
  |  By Speedscale
Mocking for testing starts off easy, but once you scale to multiple teams and AI agents, handcrafted mocks become a serious form of technical liability. Instead of treating mocking as an individual software engineering task, shift your mindset to treat it as a platform engineering task focused on automation and continuously refreshed modern data. Watch to see how adopting technologies like traffic replay to simulate realistic backend sandboxes can transform your modern testing workflow!
  |  By Speedscale
As companies adopt AI coding tools, code review processes are breaking down. Traditional compliance methods are slowing teams down, but human engineers aren't going to spend hours reading AI-generated low-level code forever. How will SOC 2 adapt to the era of AI-driven development? Drop your thoughts in the comments and subscribe for more tech insights! Learn more: speedscale.com.
  |  By Speedscale
Forecast latency, throughput and headroom before every deploy.

Continuous Resiliency from Speedscale gives you the power of a virtual SRE-bot working inside your automated software release pipeline. Forecast the real-world conditions of every build, and know you’ll hit your SLO’s before you go to production.

Feed Speedscale traffic (or let us listen) and we’ll turn it into traffic snapshots and corresponding mock containers. Insert your own service container in between for a robust sanity check every time you commit. Understand latency, throughput, headroom, and errors -- before you release! The best part? You didn’t have to write any scripts or talk to anyone!

Automated Traffic Replay for Every Stakeholder:

  • DevOps / SRE Pros: Understand if your app will break or burn up your error budget before you release.
  • Engineering Leads: Let Speedscale use traffic to autogenerate tests and mocks. Introduce Chaos testing and fuzzing.
  • Application Executives: Understand regression/performance, increase uptime and velocity with automation.

Before you go to production, run the projection.