Systems | Development | Analytics | API | Testing

This is the sixth and final post in our "Features Sitting Idle" series, where we shine a light on OctoPerf features that are already in your account, ready to save you hours every week. It's a quiet but recurring friction. Teams that test regularly all end up with a preferred report layout. But in practice, that structure is often rebuilt manually after each run, or lost entirely when moving between projects.

This is the fifth post in our "Features Sitting Idle" series, where we look at OctoPerf features that are already in your platform but often missed by the teams that would benefit the most. This one is for IT teams running OctoPerf on-premise. IT teams managing an on-premise OctoPerf instance regularly run into the same friction around SSO.

When we released the OctoPerf MCP Server, most teams connected to it straight from Claude.ai. Then we showed how to run the whole stack on-premise with a local model. But a question kept coming back from European teams: can we drive our load tests with a French LLM, hosted in Europe, instead of a US model? The answer is yes, and it takes about five minutes.

This is the fourth post in our "Features Sitting Idle" series, where we explore OctoPerf features that are powerful, already available, and yet often replaced by manual workarounds. The distinction matters, and it is often overlooked in test scenarios. Teams that need to simulate a true simultaneous spike - flash sales, ticket drops, mass logins at a specific time, scheduled batch openings - usually end up working around the problem instead of using the tool's native support for it.

But a recurring question came from banks, hospitals, defense and public-sector teams: what if nothing is allowed to leave our network, not even the prompt? This article answers that question with a full walkthrough.. We will stand up a 100% on-premise, air-gapped stack, and it only takes two things to install: OctoPerf Enterprise in Docker, and a local Qwen3 large language model running in LM Studio, which doubles as the Model Context Protocol client.

This is the third post in our "Features Sitting Idle" series, where we shine a light on OctoPerf features that are already in your account but rarely used to their full potential. This is a blind spot many teams discover too late. Tests pass, metrics look fine, yet real users report slowness or errors after a release. The root cause is almost always the same: the load test was built against the HTTP protocol layer, but the user pain happens in the browser, above that layer.

In the first two articles of this series we showed what the OctoPerf MCP Server does. This one is for the builders: how we designed it, and specifically how we kept its token cost under control. Because here is the thing nobody tells you when you start writing a Model Context Protocol server: the hard part is not exposing your API to an LLM. The hard part is not exposing too much of it.

Modern performance testing is evolving beyond the traditional choice between enterprise platforms and open-source tools. Teams increasingly need the flexibility of JMeter, k6, Gatling, or Locust combined with enterprise-grade reporting, scalability, security, and support. A new generation of platforms helps reduce operational complexity, lower total cost of ownership, and accelerate adoption through AI-assisted workflows and simplified onboarding.

This post is the second in our "Features Sitting Idle" series, where we explore key OctoPerf features that are either misused, misunderstood, or simply unknown to most users. The question comes up every iteration, and yet teams usually handle it the same way: export two reports, open a spreadsheet, and compare numbers manually. It works, but it doesn't scale. After three or four sprints, no one wants to open another spreadsheet.

We are launching with this post a new series of blog articles and LinkedIn posts titled "Features Sitting Idle". In this series, we explore key features of OctoPerf that are either misused, misunderstood, or simply unknown to our users. It's time to shine a light on these hidden gems, features that are already there, ready to become a central part of how you test. This is probably the most common situation after a load test.