Table of Contents
Try Testkube instantly. No setup needed. Experience our interactive demo environment in seconds.
Try Testkube instantly. No setup needed. Experience our interactive demo environment in seconds.
Table of Contents
At Testkube, we’re focused on helping platform engineering and DevOps teams build continuous testing into their cloud native testing pipelines. Today we’re excited to announce a new capability for GitOps organizations: listener agents.
With this release, Testkube can now trigger automated tests the moment Kubernetes resources change, across multiple clusters and namespaces. The result is faster detection of regressions, simpler orchestration of tests, and a stronger foundation for self-validating delivery systems.
Why Listener Agents Matter
Testkube environments have always used agents to listen for Kubernetes events and trigger workflows. With the growth of multi-cluster architectures, multiple namespaces, and distributed testing needs, we're expanding that model. Listener agents give you the flexibility to deploy dedicated listeners wherever you need them, unlocking new patterns for teams running tests across complex, distributed environments.
Instead of depending on a single master agent, you can now connect as many listener or runner agents as you need into as many clusters you require.
Shrinking Time-to-Detect in Kubernetes
Every DevOps engineer knows that regressions sneak into clusters through common resources like Deployments, ConfigMaps, Secrets, or RBAC. A new image, a toggled feature flag, a rotated credential, all of these can break things in subtle ways.
By tying tests directly to those resource changes, Testkube gives you immediate, context-rich feedback in the same environment your users depend on. That means broken rollouts don’t linger, regressions are caught early, and your platform becomes a self-validating delivery system. For teams working in GitOps flows, where git is the source of truth for your cluster configuration, this is especially powerful.
Moving Beyond DIY Triggers
The adoption of GitOps and asynchronous delivery pipelines raises new challenges when it comes to automated testing, one being how to trigger tests and run them in a consistent way in disconnected pipelines?
Many teams have tried to build listening and test triggering platforms themselves to support GitOps. Writing custom controllers in Go with client-go informers works, but adds maintenance overhead and fragments observability. Tools like Argo Events and Argo CD hooks can also watch resources and trigger jobs, but leave you to handle filtering, readiness checks, retries, log aggregation, and history tracking.
These approaches work, but they introduce what we like to call YAPI — “Yet Another Pipeline Instance.” It’s one more thing to maintain, govern, and integrate.
Testkube takes a different approach. With TestTriggers, you can declare which resources you want to watch — filtered by kind, namespace, labels, or event type — and point them to Test Workflows defined in the Testkube Catalog. Listener agents handle the event watching, readiness gating, and execution lifecycle. Workflows run as Kubernetes Jobs with first-class support for logs, artifacts, parameters, and metrics. And because everything is integrated into the Testkube platform, you also get history, flake analysis, governance, scaling, and observability for any test, no matter how/where it was triggered.
Of course monitoring Kubernetes resources is just one application of Testkube. Users can also use it to run more traditional continuous testing applications that today are hard coded into CI/CD pipelines. Testkube Workflows can be triggered manually, on a schedule, by CI/CD, or by API in addition to listening to Kubernetes resources. Testkube is to Continuous Testing what your CI/CD system is to the build and integration process.
What Else Is New in This Release
In addition to listener agents, we’ve introduced several other improvements:
- Concurrency and Queue Management: Queuing and Concurrency controls allow you to configure how many Workflows that can run simultaneously and be queued across your Environments and Agents.
- MCP Server Enhancements: added more granular tools for LLMs to manage and analyze workflows and provided a Docker version of the MCP Server that can be used together with LLMs in automated scenarios like ci/cd pipelines and Testkube Workflows.
- Parameter Handling: smoother ways to pass configuration into workflow executions.
Getting Started
This release is generally available today. If you’re running an on-premise control plane, you can download the upgrade from testkube.io. If you’re using our cloud control plane, you’ve already been upgraded automatically. You can also view the change log for more information.
Key takeaway
Listener agents bring native, event-driven testing into GitOps workflows without the overhead of custom controllers or external eventing systems. They make Testkube more flexible, scalable, and powerful for any team running serious workloads on Kubernetes.
About Testkube
Testkube is a cloud-native continuous testing platform for Kubernetes. It runs tests directly in your clusters, works with any CI/CD system, and supports every testing tool your team uses. By removing CI/CD bottlenecks, Testkube helps teams ship faster with confidence.
Explore the sandbox to see Testkube in action.
