See what your Tests are Actually Doing - What’s new in Testkube July 2026

If you run tests at any real scale, you already know that "the workflow passed" is not the same as "everything is fine." A workflow can go green while one test case quietly flakes every third run. A suite can stay under its time budget for weeks and then drift, and you only notice when a release slips. The signal is there. The question is whether you can see it.

For a long time the answer was: sort of. You could see pass and fail at the workflow level. For anything more precise, which test case, how often, trending in what direction, you exported data and rebuilt it somewhere else. That export step is where most teams give up. The data that would tell you what is happening lives one tool away from where you work, so you stop looking.

You should not have to leave your testing platform to understand your tests.

CI/CD tools execute workflows. Testing tools execute tests. Testkube orchestrates testing as a system, which means the execution data is already here, structured, and ready to read. This release makes that data legible. Insights now goes down to the individual test case, with the chart types and prebuilt boards to make sense of it. And a new way to run tests, Git triggers, connects your testing to your repositories so the right tests run when something changes.

‍

Insights, down to the test case

Until now, Insights showed you workflow-level outcomes. This release adds test-case-level metrics. You can track an individual test case over time, filter by name, and see its pass and fail history on its own, not buried inside the workflow's aggregate result.

This is the difference between knowing a suite is unreliable and knowing exactly which test is making it unreliable. When you can isolate the test case, you can decide whether it is a real defect, an environment problem, or a test that needs to be rewritten. The investigation that used to start with a hunch now starts with the data.

To make that data readable, Insights has new chart types: stacked bars, grouped bars, heat maps, and pass/fail ratio overlays. A heat map of failures across test cases tells you in one glance where instability concentrates. A pass/fail overlay shows you whether a fix actually held. These are the views teams were building by hand elsewhere. Now they are in the platform that already has the data.

Boards that are ready when you are

New predefined workflow boards mean you do not start from a blank canvas. Every workflow comes with a board already populated with the metrics that matter: CPU, memory, execution duration, and test-case failures, tied directly to that workflow. You open it and the relevant picture is already there.

From there the boards are yours. Customize them, save them, and share them. You control visibility with public and private modes, so a board can stay personal while you investigate or become the shared view your team checks each morning. The point is that adoption costs nothing: the value is visible before you configure anything.

Performance and load testing, now in the same view

If you run load and performance tests, this release adds more than 300 metrics for JMeter, Artillery, and k6. You can track p95 latency, CPU and memory trends, and performance stability over time inside the same Insights views as the rest of your testing.

Performance regressions are rarely a single dramatic failure. They are a slow drift you can only see across runs. Having these metrics trend alongside your functional results means you can catch that drift in the same place you already look, rather than treating performance as a separate investigation in a separate tool.

[gif or video placeholder]

Custom Metrics: visualize what you need to know

Not only does Testkube now natively surface test-case level results and performance metrics, it can ingest and visualize any metric as long as that is provided in the supported influx-based file format, for example:

• AI metrics like relevancy, accuracy, toxicity produced by AI testing tools
• Coverage metrics
• Security/compliance metrics

Git triggers: testing that reacts to your repositories

The second major enhancement in this release is Git triggers, which is available for both commercial and open-source users. You can now run tests automatically in response to events in your Git repositories, configured once per repository and applied across your workflows. It is provider-agnostic, so it works with the Git provider you already use, no need to create custom scripts in your git platform.

For GitOps and CI workflows, the operational impact is direct:

• No hand-built pipeline config for each repository: set up the trigger once and it applies across your workflows.
• No write access required to run the right tests: tests can fire from repository events, so people who do not have write access to the repo can still get the runs they need.
• Testing that follows your changes: trigger runs on pull requests, on branch updates, and when the test definitions themselves change, including infrastructure tests when cluster configuration changes.

This is what it means to orchestrate testing as a system. The tests do not wait for someone to remember to run them. They respond to the work as it happens.

What this adds up to

Everything in this release shortens the same distance: the distance between something changing and you understanding what it means for your tests. Git triggers close that gap at the front of the loop, when code or infrastructure changes. Insights closes it at the end, when you need to know what your tests are telling you, down to the individual case.

Get started

We are looking forward to seeing how this release helps your team get more out of Testkube. To explore everything that shipped, check out the full documentation.

The latest enhancements are available now. Sign up and explore the full control plane and look at what your tests have been doing all along.

There is more on the way. Stay tuned.