|
By Matthew LeRay
We shipped v2 of a small products API on a Thursday. Green CI. Green replay. The new search endpoint worked. I went home feeling competent. Friday morning I ran the same traffic against both builds with proxymock and compared the SQL. v2 had added 80 queries on the same HTTP script. A per-product audit COUNT was firing inside the list handler. A startup migration had run ALTER TABLE and CREATE TABLE audit_log. Total DB time was up 70 ms on a demo that should have been boring.
|
By Matthew LeRay
A customer emailed on a Tuesday: checkout hung for ten seconds. I opened our tracing tool, punched in the time window, and got nothing. The trace was sampled out. We keep 1% of traces, like most shops with real traffic do. The one request that actually mattered was in the 99% we threw away. I spent twenty minutes admiring our observability stack before admitting it couldn’t answer a first-grader’s question: what happened to this person? Here’s what I know now.
|
By Matthew LeRay
It was 2am and I was paying for the privilege. Something was on fire in production, and I’d done the modern thing: I pointed an AI agent at it. It ingested the dashboards. It read the logs. It walked the traces. Then it handed me back a beautifully formatted paragraph that said, in effect, “latency is elevated on the checkout path.” I knew that. The page told me that.
|
By Ken Ahrens
In the first experiment, I wanted a baseline: if an AI coding agent gets the same production signal a human would get, can it fix bugs in a codebase it has never seen? Yes, but only when I gave it better context. With only an alert, the agent passed 51% of the runtime tests. When I added captured traffic, the actual request and response for the failing call, it climbed to 77%. This post is the second pass.
Sponsored Post
|
By Matthew LeRay
A customer escalation hit my queue when I was on the customer smoke jumpers team at an observability vendor. My team was the group that parachutes into Fortune 500 accounts one bad week from churning and usually after a big customer outage. The customer had filed a billing dispute three weeks earlier and their on-call engineers were stuck. They had our full stack: logs, metrics, traces, end-to-end instrumentation, every product we sold and some we didn't. They could see the request came in. They could see it returned a 500. They could not see the body. The trace was sampled out. The log line was truncated at 4KB.
|
By Speedscale Team
If you run a platform tools or security team, you have likely heard this request from developers: “I just need a copy of the production database for staging so I can run realistic load and integration tests.” It is a completely reasonable request. Production traffic and data contain the actual request shapes, real-world value distributions, long-tail anomalies, and timing patterns that make tests useful.
|
By Ken Ahrens
I’m a big fan of service mocking. I’ve been working in and around software for about 25 years, and one thing never changes: when you sit down to work on your code, you almost never have everything available. The database, the third-party API, the message queue, the service two teams over. Something’s missing. So you’ve got to stub it out or mock it out and keep moving.
|
By Ken Ahrens
We’ve gotten used to understanding our applications through signals, summaries, and traces. Tiny little bits of information about how the app really works. Not because that’s the best way to do it, but because it’s been too hard to get the real thing. The real information exists. It’s on the network. How people called your app and what your code did. What other systems it called, the database queries it made, and the result sets that came back.
|
By Ken Ahrens
Trigger warning: this one is about Java, authentication, and Docker Compose files. If that is not your thing, I am sorry, but they are part of life and they are honestly not that hard to work with. Everything here is open source on our GitHub repo, so you can follow along. Recording an authenticated Java flow, replaying it, hitting the dreaded 403, and fixing it with a proxymock recommendation.
|
By Ken Ahrens
Every enterprise contract I’ve signed in the last two years has the same clause. “Vendor will not use Customer Data to train machine learning models.” Sometimes it’s a paragraph. Sometimes it’s a whole section. The language varies but the intent is identical: don’t feed our production data into your AI. I get it. I sign the same clause as a vendor. But here’s what’s been bothering me: that clause is a promise, not an architecture.
|
By Speedscale
AI agents write broken code nearly 50% of the time. By adding a traffic-based deterministic evaluation, Speedscale boosted unsupervised bug-fixing quality from 51% to 77% in just 5 minutes. This helped slash token costs and eliminate rework without human intervention. Learn more: speedscale.com.
|
By Speedscale
Tired of outage after outage? Use traffic replay to automatically generate regression tests for your CI pipeline in just a few clicks. Take back your time! Read more at speedscale.com.
|
By Speedscale
They look perfect together on paper, but the reality? Not so much. What do you think of this combo?
Dynamic IDs? Now Vibecode With Confidence #speedscale #vibecode #automation #softwaretesting #devops
|
By Speedscale
Learn more: speedscale.com.
|
By Speedscale
Stop dynamic IDs from breaking your integration tests! Tired of manual copy-pasting for IDs in your test cycles? Learn how to use proxymock to help: Check out proxymock.io to get started for free!
|
By Speedscale
Learn how to resolve the 403 authentication error when replaying API traffic using proxymock. This video demonstrates how to: All tools and demo code are open source and available on GitHub. For more information, visit proxymock.io.
- July 2026 (4)
- June 2026 (27)
- May 2026 (19)
- April 2026 (27)
- March 2026 (20)
- February 2026 (20)
- January 2026 (30)
- December 2025 (15)
- November 2025 (12)
- October 2025 (14)
- September 2025 (16)
- August 2025 (14)
- July 2025 (8)
- June 2025 (1)
- May 2025 (4)
- April 2025 (16)
- March 2025 (10)
- February 2025 (1)
- January 2025 (7)
- December 2024 (13)
- November 2024 (9)
- October 2024 (24)
- September 2024 (13)
- August 2024 (10)
- July 2024 (4)
- June 2024 (4)
- May 2024 (2)
- April 2024 (5)
- March 2024 (4)
- February 2024 (3)
- January 2024 (1)
- December 2023 (3)
- November 2023 (3)
- October 2023 (4)
- September 2023 (2)
- August 2023 (13)
- July 2023 (2)
- June 2023 (4)
- May 2023 (2)
- April 2023 (2)
- March 2023 (7)
- February 2023 (6)
- January 2023 (4)
- December 2022 (3)
- November 2022 (4)
- October 2022 (2)
- September 2022 (3)
- August 2022 (5)
- July 2022 (5)
- June 2022 (2)
- May 2022 (4)
- April 2022 (4)
- March 2022 (4)
- February 2022 (14)
- January 2022 (6)
- December 2021 (3)
- November 2021 (4)
- October 2021 (5)
- September 2021 (5)
- August 2021 (6)
- July 2021 (5)
- June 2021 (6)
- May 2021 (6)
- April 2021 (2)
- March 2021 (5)
- February 2021 (2)
- January 2021 (2)
- November 2020 (1)
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.