Validate entire system behaviors before production failures occur.
System Graph maps how your services are supposed to work. OpenTelemetry captures what they actually do. The LLM generates scenarios, explains failures, and adapts tests automatically.
From testing to validation.
Testing asks: "Did the test pass?" Validation asks: "Is the system correct?" These are fundamentally different questions.
- —Test isolated endpoints
- —Assert HTTP status codes
- —Mock external dependencies
- —Pass/fail per request
- —Coverage measured by lines of code
- —Catch regressions after the fact
- ✓Validate full service interaction chains
- ✓Assert correct events, DB state, and timing
- ✓Run against real system behavior via OTel
- ✓Pass/fail per system scenario
- ✓Coverage measured by real production flows
- ✓Prevent incorrect system behavior before deploy
The category TestMesh creates
System Validation Platform
Not a QA tool. Not a testing framework. Not an API tester. A platform that understands your architecture, observes real system behavior, and automatically validates that your entire backend is correct — on every deploy.
Distributed systems have a validation gap.
Modern backends are distributed, event-driven, and complex. Testing is still endpoint-based, manual, and incomplete.
No system-level testing exists
Teams test APIs, UIs, and units — but nobody tests service interactions, event flows, or data consistency across the full chain. The system behavior between services is a blind spot.
"Works locally, breaks in prod"
Distributed systems fail in ways unit and API tests cannot catch: async timing, partial failures, retry storms, race conditions. These only surface under real system behavior.
QA cannot keep up with engineering speed
Manual integration testing is too slow and too expensive to run on every deploy. Automation exists for UI flows and endpoints — but backend correctness across services remains largely unverified.
Observability shows what happened — not what should happen
Datadog and Grafana tell you a service crashed. They cannot tell you whether the system behaved correctly. Monitoring is not validation.
Not just a test runner. A validation system.
Three layers of intelligence work together to validate your entire distributed system — not individual endpoints.
System Graph
Maps how the system is supposed to work — services, APIs, queues, and databases and their relationships. The source of truth for what correct behavior looks like.
Telemetry
Uses OpenTelemetry to observe real-time behavior across your distributed system and detect drift from the expected graph.
LLM
Generates test scenarios from your actual traffic, explains failures in plain language, and adapts your test suite automatically when the system changes.
Your test suite as a living diagram.
Build and debug integration tests on a spatial canvas. Each action is a node — HTTP, Kafka, Redis, gRPC — connected by bezier curves that show data flow. Click any node to configure it. The YAML syncs in real time.
Your system already knows what to test.
When OpenTelemetry is connected, TestMesh detects real flows from live traffic — API call chains, Kafka fan-outs, cache patterns — and generates a test suite from actual behavior rather than assumptions.
- ✓Detects multi-service call chains from OTel traces
- ✓Identifies Kafka fan-out patterns automatically
- ✓Flags untested paths appearing in production traffic
flow:
name: "Discovered: Order Lifecycle"
# Auto-generated from OTel trace 2026-04-14T09:32:11Z
steps:
- id: create_order
action: http_request
config:
method: POST
url: "{{BASE_URL}}/orders"
assert:
- status == 201
output:
order_id: $.body.id
- id: verify_event
action: kafka_consumer
config:
topic: "order-events"
timeout: 10s
assert:
- messages[0].value.order_id == "{{order_id}}"Agentic scenario generation.
TestMesh reads your system graph, observes real traffic, and generates the scenarios that actually matter — not the ones a developer thought to write.
Generated automatically
- Happy pathFull successful flow across all services
- Failure scenariosTimeout, retry, partial failure, cascade
- Edge casesEmpty payloads, duplicate events, out-of-order messages
- Load patternsBurst traffic, consumer lag, backpressure
CI/CD integration
Runs on every deploy. Blocks broken releases.
Drop TestMesh into your pipeline. On each deploy, it re-validates the full system graph against real behavior. A single incorrect interaction blocks the release.
Real coverage
Coverage based on reality — not lines of code.
TestMesh measures what percentage of your real production flows are validated. Not which lines were executed. Fake coverage metrics don't catch production failures.
Self-adapting flows
When your system changes — a new service, a renamed event, a schema migration — TestMesh detects the drift and updates affected flows automatically. No broken tests after every refactor.
Built for when things go wrong.
Not just finding failures — understanding them.
Failure Simulation
Inject faults directly into flows to validate degradation behavior before it happens in production.
- ✗Kafka message delays and partition failures
- ✗Database connection timeouts
- ✗Network latency and packet loss
- ✗Retry storm simulation
Root Cause Analysis
When a flow fails, TestMesh diffs the Expected Graph against the Actual OTel Trace and pins the exact divergence point.
Every protocol your stack uses
HTTP & REST
Assert status, headers, and body with expr-lang expressions.
action: http_requestKafka
Produce messages and consume to verify async event flows.
action: kafka_consumerDatabases
Query PostgreSQL directly and assert on rows after API calls.
action: database_querygRPC
Call unary and streaming gRPC services by method name.
action: grpc_callWebSocket
Connect, send messages, and assert received payloads.
action: websocketRedis
Read and assert cache values after service operations.
action: redis_getFrom zero to tested in 3 minutes
Install the CLI, write a flow, run it. That's it.
# macOS / Linux
curl -fsSL https://testmesh.io/install.sh | sh
# Homebrew
brew install test-mesh/brew/testmesh
# npm
npm install -g @testmesh/cli
testmesh --helpWhat actually breaks in production — and what you test today.
Postman, k6, and Cypress are excellent tools. None of them validate system behavior. That gap is what TestMesh fills.
| Validation requirement | Postman / k6 / Cypress | TestMesh |
|---|---|---|
| Correct services were called in the right order | ✗ No | ✓ Yes |
| Correct Kafka events were emitted with correct payloads | ✗ No | ✓ Yes |
| Database state is correct after the full chain executes | ✗ No | ✓ Yes |
| Retries and timeouts behave correctly under failure | ✗ No | ✓ Yes |
| Race conditions and partial failures are handled | ✗ No | ✓ Yes |
| All downstream side effects occurred (cache, notifications, etc.) | ✗ No | ✓ Yes |
| Individual API endpoints return correct status codes | ✓ | ✓ Yes |
| Services pass their own unit tests | ✓ | ✓ Yes |
Keep using your existing tools for what they're good at. Add TestMesh for what they can't do.
TestMesh Cloud
Multi-tenancy, SSO, AI agents, GitHub integration, and a hosted control plane — built on the same OSS engine. One-click deployment, zero infrastructure to manage.
Stop testing protocols in isolation.
Write one flow that validates the whole chain.