Atlanta, GA, USA
2020
  |  By Matt LeRay
A metric says latency increased. A log says a request failed. A trace identifies the slow dependency. An APM agent points to the method. Manual instrumentation explains the business operation. Traffic capture shows the exact request and response that triggered it. Each layer answers a question the previous layer could not. Each also introduces a new cost, blind spot, and failure mode.
  |  By Matt LeRay
Engineering leaders have been claiming to “shift quality left” for years but production remains stubbornly stuck out of reach of software engineers. The realm of production remains mysterious with tools no one has access to and UIs that wouldn’t make sense to engineers anyway. I’ve noticed a small but growing trend of large enterprises hiring Reliability Engineers instead of Site Reliability Engineers. Dropping one word looks cosmetic but I think it points to a much bigger change.
  |  By Matt LeRay
We shipped a chaos feature that never caused any chaos. Our mock server has had a fault-injection effect for years with a straightforward job: withhold the response entirely and see whether the caller copes. Last week I audited it against the actual code path. It had never withheld anything. The handler returned early without writing a response. Go’s net/http then did what it is designed to do, which is synthesize a 200 OK and flush the recorded body.
  |  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.
  |  By Matt LeRay
The request timed out after five seconds. The application said context deadline exceeded. The dependency was healthy, its dashboards were green, and its own latency histogram showed nothing above 30 milliseconds.
  |  By Matt LeRay
Every SRE team operates services it cannot see into: a vendor binary, an inherited legacy deployment, a container whose owning team dissolved two reorgs ago. The routes are undocumented, the dependencies are unknown, and when a request takes 130 milliseconds nobody can say whether that time is application work or a wait across a network boundary.
  |  By Matt LeRay
I made an API endpoint 13 times faster. Then I realized my first verification only checked the status, headers, and response schema. I had not checked the totals. I had made the bug faster. That is the problem with giving an AI coding agent one kind of evidence. A CPU profile can show where the application is slow, but not whether an optimization preserves behavior. A traffic replay can prove that behavior stayed stable, but not explain why the code burns CPU. This walkthrough gives the agent two independent witnesses: Together, they turn AI code verification into an experiment with two independent checks.
  |  By Matt LeRay
A smaller Kubernetes pod can lower allocation cost while completing less work. Green status codes and matching schemas can hide it. This walkthrough combines OpenCost allocation data with proxymock behavior and performance evidence. A candidate passes only when behavior and throughput hold while unit cost falls.
  |  By Matt LeRay
One API request took 302 milliseconds. Nothing failed. CPU was mostly idle. The response was correct. The trace made the problem obvious: eight inventory calls, each waiting for the previous one. But the trace could not tell me why the application made eight calls, or whether changing their execution would preserve the response. It showed the shape of the wait, not the input that created it.
  |  By Shaun Duncan
Recently someone on our team opened a traffic snapshot and found an HTTP request that was captured with our eBPF capture agent, nettap. Our protocol dissector parsed most of the response correctly, but that correctness ended once the response headers were processed. What they ended up with was a recording of an HTTP request/response where the response body was just an incorrect collection of garbage binary data when it should have been JSON text.
  |  By Speedscale
This video provides a step-by-step demonstration of how to record an application's real-world traffic and generate an automated sandbox environment for debugging and testing.
  |  By Speedscale
We spend thousands of dollars "token maxing" and running endless debugging cycles just to walk our LLMs through a problem. But is the AI actually failing, or are we just withholding the right environment? Giving your AI assistant its own sandbox to test hypotheses might just be the missing link in your development workflow.
  |  By Speedscale
Tired of out-of-control log expenses and manual logging discipline? Discover next-generation observability with Speedscale. By using eBPF to record full-fidelity data right off the wire, you can instantly run full-text searches, track down leaking PII, and securely map out credentials across HTTP, Postgres, gRPC, and more—all without writing a single log line. Learn more: speedscale.com.
  |  By Speedscale
Fighting AI Slop: The Missing Ingredient for Clean Code.
  |  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.