Runtime coverage · ReplayOps sessions · Test impact
CoverOps attaches lightweight agents to your running services and turns every functional test, automated or manual, into line-level coverage and a cross-service call tree, joined to the ReplayOps session it happened in.
One flag per service · first coverage in minutes · no code changes
The parts people remember
Sessions come from ReplayOps, whose SDK stamps the session id on every request the page makes. The agents read it, so each click a person made is joined to the services it reached and the methods and lines it executed. The picture of the session stays in ReplayOps, one link away; what lives here is what it touched in your code.
Click any test and see the steps the person took (Open, Navigate, Click, Input) as ReplayOps saw them, beside the request hops they caused and the files they covered. Every red block in a file names the nearest scenario that reached it, with its steps and a link to watch the session where it happened.
A ReplayOps session needs no test name to count. Every visit the agents saw is listed with the services it reached and the requests it made, and a line of code can say how many real sessions ran it. That is the dead-code question answered from the other end.
Each session unfolds as a New-Relic-style trace: every service hop with the classes and methods that actually ran, framework plumbing folded away. Click a red block in any source file and CoverOps hands you the recorded scenario that exercises it.
What you actually see
Every file opens like this: green ran, red never did, amber took one branch and not the other. Hover a line to see which tests executed it. Every red block names the nearest scenario that reached it, with its steps and the ReplayOps session to watch.
Who ran line 133
Per-test attribution, across service hops: the platform knows which lines each Playwright, Cypress or manual session executed.
Changed-code gate, this branch
One CLI call, exit 0/1/2, a commit status on the PR. The repository average stays flattering; this number tells the truth about today.
What the agents build
Every one is made from the same traced calls the agents already report. Nothing here is maintained by hand, which is why none of it goes stale the week after it is drawn.
Drawn from the calls that actually happened, so a service nothing reaches has no edge to hide behind. Colour is coverage: green ran, amber ran partly, red is code your tests never touched.
A commit names the lines it changed. The footprint says which tests walked those lines, so a pull request runs the four that can fail, not the four hundred that cannot.
A ReplayOps session stamps every request the page makes with W3C trace context and its session id. The agents read it, so each step a person took names the services it reached and the methods that actually executed. The recording stays over there; the code it ran is over here.
Coverage read backwards. Over a window you choose, in the environment you choose, these are the methods the agents watched and nothing ever reached: the safest thing to delete and the first thing to question.
The gate
Total coverage is a vanity metric: it barely moves, whatever you do to it. The question a release actually turns on is narrower: did this change get covered? The gate answers that for the lines the pull request touched, and nothing else.
CoverOps / changed-code coverage
86% · 27 of 31 changed lines · required 80%
CoverOps / changed-code coverage
61% · 19 of 31 changed lines · required 80%
CoverOps / changed-code coverage
no run measured these files; reported as missing data, not as a pass
The threshold is yours, per project. Leave it unset and the gate still reports; it simply stops blocking, which is the honest way to roll one out.
The pipeline asks with the agent token it already holds. Passing the pull request's own commits makes the answer exact for that branch.
curl -sf -H "authorization: Bearer $COVERAGEOPS_TOKEN" \ "$API/v1/agent/gate?shas=$PR_COMMITS&min_changed=80" \ | jq -e .passed
It always answers 200 with a verdict and lets the caller decide. A coverage service that can fail your build by being unreachable is a coverage service that will.
Platform
Java (bytecode), Node (V8), .NET Core and Framework (IL weaving), Python, Go and PHP agents attach with one flag: no code changes, under 1% overhead. Parallel shards merge into a single run.
Every request carries its test's identity across service hops, so the platform knows which lines each Playwright, Cypress, Selenium or manual test actually executed.
Connect git, pick a date, and the diff is matched against what every test touched on its last run. Schedule only the impacted cases: minutes instead of hours.
A regression that runs over days, mixing automation and manual testing? Turn monitoring on; every agent joins, resets and accumulates until you stop it.
Built from recorded traces, not a diagram: which services requests walk through, in what order, and which methods run hottest, as APM-style cards you can zoom and pan.
A product can span many repositories and services. Define projects, choose which services and repos each one watches, and share common ones between them.
Playwright, Cypress, Selenium/JUnit 5, Postman, k6, GitHub Actions, Jenkins, GitLab CI, Kubernetes auto-attach, plus a plain REST API for everything else.
Catalogue cases flow in from Jira, Xray and TestRail; verdicts and the coverage behind each case flow back, so a case says what code it exercised, not only whether it passed.
How it works
One JVM flag, one NODE_OPTIONS entry or one .NET startup hook per service, or a single Kubernetes annotation for the whole cluster.
Functional suites, UI automation, load tests, manual click-throughs. Each test names itself in a header; the agents do the rest.
Line-level coverage per service, per file and per test, with the gaps your suite never reaches called out explicitly.
The next release only needs the tests its diff impacts. The platform picks them, schedules them and reports the verdicts.
Integrations
25 are live today: source control, test automation, CI, test management, alerting and the language models. It plugs into the pipeline you already run rather than asking for a new one.
Request a demo
Thirty minutes, your questions first. We will walk a multi-service demo and map it to your stack: coverage per test, a ReplayOps session down to the code it ran, the changed-code gate. No slides unless you ask for them.
We use these details only to reply about the demo.
Attach the first agent in minutes. The first run tells you what your tests really reach, and what they never have.
Get started