Know what your change breaks before you ship it.
Once a backend is a hundred services deep and split across teams, nobody holds the call graph in their head — so every change is a bet against an outage. Cotracer follows the change through your production traces, logs and code to the services that actually depend on it — wherever they live — and reports the blast radius with evidence: which services break, how, and at what traffic volume. And when production does break, it works backwards to the root cause.
consumers. checkout computes order totals from it and will
silently produce 0.00 — no exception, no alert.
Your AI reviewer reads one repo. The damage happens in the others.
AI code review is good at the diff in front of it — style, bugs, edge cases, all inside the one repository it was given. It has no idea which four services call the endpoint you just changed, because none of that is in the repository. In a distributed backend, that is where nearly every incident comes from.
The org chart makes it worse: each team owns its own group of services, and no developer really knows what happens inside another team's. Cotracer does — it's the one thing in the company that has read all of them. It works at the level of your whole organisation: it follows the changed code outward through production traffic, other teams' repositories, logs and tickets, and re-evaluates with each new fact until it can prove what breaks. Every fact it needs has been sitting in your observability stack all along — nobody ever put it in front of the engineer changing the code. That's the product.
You'll never see a “potential risk” paragraph. Every claim carries the query that produced it.
price_usd from productcatalog.GetProduct. Three services read that field in production in the last 24h.price until checkout migrates.A CI check that can actually hold the line.
One-shot, structured output, exit code 1 on HIGH risk. Drop the workflow in and every PR gets an evidence-backed verdict — as a check, a comment, or JSON for your own tooling.
Ask why it broke. Or why it exists.
When production breaks, point Cotracer at the failure: it works backwards through traces, logs, git history and old PRs to the change — and the reasoning — that caused it. The same loop answers the questions you'd otherwise spend a morning on: who wrote this service, which ticket demanded it, and which of the other ninety-nine still depend on it. Built for distributed backends whose authors left years ago.
“The code authors left the job a few years ago, no one understands the system anymore, and there are about a hundred microservices. Before any change I had to trace the whole system by hand.”— why we're building Cotracer
company in 2023. The PR implements CART-482 — “show
prices in cart” — because cart had no currency service
at the time. It does now: currencyservice, added 2024.
The field is redundant for cart, but not for checkout,
which never migrated.
Whatever you already run, we already read it.
Point Cotracer at the observability stack your services already report into. One config file, nothing to instrument, nothing to migrate. Adapters are built per capability, not per vendor — design partners' stacks go to the front of the queue.
Jaeger
Datadog APM
New Relic
AWS X-Ray
Google Cloud Trace
OpenSearch
Elasticsearch
SplunkDatadog LogsAWS CloudWatchGoogle Cloud Logging
Azure Monitor
Grafana Loki
Sumo Logic
PrometheusGrafanaDatadog MetricsNew RelicCloudWatch Metrics
Sentry
Rollbar
GitHub
GitLab
Bitbucket
JiraThere is no cloud in the request path.
The backend runs inside your network. Prompts and tool results — your production logs and traces — never transit a Cotracer service. Bring your own model endpoint and pay the provider directly.
That makes Cotracer deployable where SaaS AI tools are non-starters — fintech, healthcare, public sector, air-gapped estates — and makes its security review the shortest your team will run this year.
Developer / CI
│
▼
┌──────────────┐
│ Cotracer CLI │
└──────┬───────┘
│ HTTPS
▼
┌──────────────────────┐
│ Cotracer Backend │
│ (your infra) │
└──┬────────────┬─────┘
│ └──▶ your LLM
├──▶ GitHub / GitLab
├──▶ Logs · Traces
└──▶ Errors · JiraTwo ways to buy it
Same backend either way. The difference is who holds the model keys.
Subscription
Backend in your infra, Cotracer-supplied model keys, per-seat monthly. Best for small teams who don't want to run an LLM contract.
Annual license
Backend in your infra, your own model endpoint and key, yearly license. Built for enterprises with a security review and an existing LLM contract.
The questions engineers actually ask
Mostly from platform and backend teams running dozens of services. Anything missing, ask us directly — a human answers.
Do we have to instrument anything?
No. Cotracer reads the telemetry you already emit through your existing tools. There's no SDK to add, no agent to deploy in your services, and no change to how you trace or log today.
Does our code or telemetry leave our network?
No. The backend runs inside your infrastructure and talks to your model endpoint directly. There is no Cotracer service in the request path, so prompts, logs and traces never transit us.
Which model does it use?
Yours. Point it at any OpenAI- or Anthropic-compatible endpoint — hosted or self-hosted — and pay the provider directly. We certify a small set of models we've tested hard; others work best-effort.
We already use an AI code reviewer.
Keep it — it reviews the code in the PR, which Cotracer doesn't do. Cotracer answers the question your reviewer structurally cannot: what does this change break somewhere else in the organisation. It reads production traffic and other teams' repositories, and cites the query behind every claim.
Our callers live in other teams' repos.
That's the whole reason it exists. It searches across the repositories your VCS exposes, so a field removed in one service surfaces the three others still reading it — including the ones owned by teams you'd never have thought to ask.
Does it run in CI or on my machine?
Both. In CI it's one-shot with structured output and an exit code you can gate merges on. Locally it analyses uncommitted work in your checkout and answers follow-up questions interactively.
What can it do to our repository?
Read it, nothing more. Local operations are a fixed set of read-only git and file commands, path-jailed to your checkout. There is no arbitrary shell and nothing writes back.
What happens when it's wrong?
Every verdict shows its evidence, so you can check the reasoning instead of trusting a score. Start it as an advisory comment; turn on merge-blocking once your team trusts what it finds.
How many services can it reason about?
It doesn't load your topology up front — it follows the changed code outward, one hop at a time, so cost scales with the blast radius rather than the size of your estate. Hundreds of services is the case we designed for.
What does the pilot commit us to?
Nothing but feedback. Design partners get a discounted license, help with the deployment, and direct influence on what we build next. You can stop whenever it stops being useful.
Our stack isn't in your list.
Tell us what you run when you apply. Integrations are built per capability rather than per vendor, so adding a new one is an afternoon — not a roadmap item.
Stop tracing the system by hand.
We're onboarding a small number of design partners running real microservice estates. Deploys on-prem against your own observability stack — your data stays with you. The bar we hold ourselves to is simple: prevent a real outage in your infra.