Runtime coverage · Session replay · Test impact
CoverOps attaches lightweight agents to your running services and turns every functional test — automated or manual — into line-level coverage, a replayable session and a cross-service call tree.
One flag per service · first coverage in minutes · no code changes
The parts people remember
Every recorded test — automated or a tester clicking through — plays back pixel-for-pixel from a DOM recording that costs kilobytes, not video files. Console, network with request/response bodies, Web Vitals, DOM changes and backend hops sit on the same clock: click any row and the player seeks to that exact moment.
One click packs a session's user steps into a link; opening it replays them on the running application — clicks, typing, navigation — while a live step list marks progress. Flip on debug mode and advance step by step with the space bar. The re-run records itself and carries the name of the person who launched it.
The in-page widget records named sessions, replays catalogue cases, and captures the screen when something is wrong. Draw arrows, boxes and notes over the screenshot — the annotated capture lands in Jira as an attachment on the bug, with the session linked.
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 — and every red block offers the nearest recorded scenario that would reach it, one click to replay.
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 recorded session stamps every request the page makes with W3C trace context. The agents read it, so each step of a replay names the services it reached and the methods that actually executed — a tester's bug report arrives with the backend already attached.
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.
Import cases into the catalogue, sync run verdicts back, and file tester bugs — with annotated screenshots attached — straight into your Jira project.
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
20 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 — coverage per test, session replay, the changed-code gate — and map it to your stack. 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