Observability you
can simply ask.
Logs, metrics and traces on one correlation key, an AI that writes the query and the RCA, and open standards end to end — so nothing here holds your data hostage.
OpenTelemetry in · open formats out · no lock-in anywhere
- 1 PB
- validated data cycle
- tested, not projected
- 2×
- peak ingest load-tested
- headroom by default
- 80M
- spans in the live demo
- query it yourself
- 0
- proprietary agents
- pure OpenTelemetry
Three pillars. One correlation key. No dead ends.
Most stacks bolt logs, metrics and traces together after the fact, and every investigation pays the toll at the seam. ClarityNxt attaches one shared correlation key at ingest — so moving from a slow trace to the logs that explain it is navigation, not a new query.
Logs
OTel log ingestion queried interactively — typed filter chips, facet cardinality, a severity histogram you can zoom, and live tail.
search · facet · tail
Metrics
OTel metrics feeding dashboards, alert aggregations and the statistical baselines anomaly detection runs against.
aggregate · baseline · alert
Traces
Span ingestion with full waterfall reconstruction and a dependency-aware service map that draws itself from live traffic.
waterfall · topology · latency
trace_id→logs↔metrics↔tracesa versioned cross-team contract, not an internal detailEverything the platform does. All of it, working today.
Nine capability areas, every one shipped and running in the live demo you can open right now. Nothing below is a preview, a waitlist, or a paid add-on.
NLP querying
Natural-language questions translated to SQL against your telemetry, with clarifying responses for ambiguous input rather than silent empty results.
AI assistant
AI remediation & RCA
Alert breaches become a written root-cause analysis: timeline, span table, remediation commands and prevention. It reads traces, logs and metrics, then the codebase, your cloud and cluster, and configuration and flag state. Advisory by design — it never executes anything itself.
AI assistant
Anomaly detection
Continuous statistical baselining with false-positive rate measured against a baseline before any detector is surfaced or wired to alerting.
Detection
One-click instrumentation
Point it at a repository and it injects the OpenTelemetry SDK, branches, and opens a ready-to-merge pull request. Multi-stack, not one reference language.
Onboarding
SSO + RBAC
OAuth and SAML with role mapping, plus a local break-glass login so an identity-provider outage is not also an observability outage.
Access control
Archive & restore
Open Parquet on object storage with a Hive schema — readable by anything, configurable targets, restore validated against a stated RTO.
Retention
Deploy anywhere
One-command bootstrap, Kubernetes and VM targets, variable-driven replica and frontend scaling, dynamic scale up and down.
Platform
Live integrations
Git, Kubernetes and AWS, GCP and Azure access, LLM providers and alert destinations are all database-backed and UI-managed — keys AES-encrypted, changes applied without a restart.
Integrations
E2E release gate
A CI suite covering log search, dashboards, trace lookup and alert firing gates every release. Shared ownership, not one team's chore.
Quality
Seven surfaces, one workspace. These mocks are live — click them.
Every panel below is an interactive reproduction of the real product page it names. Zoom a histogram, drag an alert threshold, switch a dashboard variable, walk a trace.
Ask Clarity AI
NLP → SQLNatural language over otel_logs, otel_traces, otel_metrics
SELECT COUNT(*) AS error_count
FROM otel_logs
WHERE service_name = 'recommendation'
AND severity_text IN ('ERROR', 'FATAL')
AND timestamp >= CURDATE()
ORDER BY error_count DESC;| error_count |
|---|
| 1,284 |
summaryThe recommendation service logged 1,284 errors today — a 3.1× increase on its 7-day average, concentrated between 09:12 and 09:40 UTC.
/askAsk in English. Get the query, the rows and the answer.
A question goes through a prompt carrying your telemetry schema, generation, reflection retries on malformed output, then read-only execution and a summarisation pass. Follow-ups are rewritten to be self-contained, so "what type of errors are these?" resolves against the previous turn.
- Natural language → SQL, shown to you before it runs
- Read-only execution — multi-statement support disabled
- Ambiguous questions get a clarifying response, never a best guess
- Multi-turn context rewriting for follow-up questions
Your best engineer shouldn't be the one who memorised the schema.
Natural-language querying isn't a novelty layer here — it's how most investigations start. A question goes in, the SQL it produced comes back visible, the rows execute read-only, and a summary tells you what the numbers mean.
Read-only by construction
Generated SQL executes with multi-statement support disabled against a read path. The query is shown to you before it runs, every time.
Clarifies instead of guessing
An ambiguous or malformed question comes back asking for the missing detail. A silent empty result set is the one answer we refuse to give.
Reflects on its own output
Malformed generations are retried against the schema up to a bounded reflection limit — and if SQL still can't be formed, it says so plainly.
Ask Clarity AI
NLP → SQLNatural language over otel_logs, otel_traces, otel_metrics
SELECT COUNT(*) AS error_count
FROM otel_logs
WHERE service_name = 'recommendation'
AND severity_text IN ('ERROR', 'FATAL')
AND timestamp >= CURDATE()
ORDER BY error_count DESC;| error_count |
|---|
| 1,284 |
summaryThe recommendation service logged 1,284 errors today — a 3.1× increase on its 7-day average, concentrated between 09:12 and 09:40 UTC.
The incident review is written before your first meeting.
When an alert breaches, the assistant pulls the traces, logs and metrics around it — then goes further, reading the codebase and querying your cloud and cluster control planes end to end. What comes back is a written analysis: root cause, timeline, remediation steps and prevention. Below is real generated output from the demo environment.
AI Root Cause Analysis
advisoryFrontend product view failure · detected 2026-09-12T16:05:04.804Z
1. Executive Summary
At approximately 2026-09-12T16:05:04.804Z, users experienced failures when attempting to view product details via the /api/products/[productId] endpoint. The root cause was traced to the product-catalog service returning an intentional failure due to an enabled feature flag. This cascaded to the frontend and frontend-proxy services, resulting in user-facing errors.
It follows the blame across services
The alert fires on frontend. Six spans across four services all show errors, and the only one that explains anything is the deepest. Correlated telemetry makes that chain walkable — and the analysis does the walking.
It doesn't stop at telemetry
Traces, logs and metrics establish the failure chain. Then it reads the repository, queries your cloud and cluster — AWS, GCP, Azure, Kubernetes, GitHub — and checks configuration and feature-flag state. In the incident below, every service looked broken and none of them were: the cause was a flag, and telemetry alone would never have said so.
You get a document, not a hunch
Executive summary, timeline, technical root cause with the span table, remediation steps with the exact command to run, and preventative measures. Copy it as Markdown straight into your incident record.
Advisory, permanently
It hands you the command to flip the flag back. It does not run it. No auto-execution path exists, not even behind a flag of its own — because an observability tool that can change production is a different risk conversation.
Instrument a service by pointing at its repository.
No copy-paste SDK ceremony and no hand-written collector config. ClarityNxt reads the repo, writes the OpenTelemetry wiring on a branch, and opens a pull request — so instrumentation arrives as reviewable code, not as a black box.
Nothing reaches your default branch without a human approving the diff. The PR is the audit trail.
Open standards at every boundary. Nothing proprietary in the path.
Telemetry arrives over OTLP from unmodified OpenTelemetry SDKs, lands in an open columnar store queried with standard SQL, and archives to Parquet you can read with anything. No proprietary agent, no bespoke wire format, no query language you can only use here — if you ever leave, your data and your instrumentation come with you.
Run it as a service, or run it yourself. Same product.
There is no cut-down self-hosted edition and no feature held back for the managed tier. Pick the operating model that fits your data policy, and change your mind later without a migration project.
GDPR compliant
Lawful-basis documentation, data-processing agreements, subject access and erasure workflows, and EU data residency on request.
DPDP compliant
Aligned to India's Digital Personal Data Protection Act — consent and notice handling, purpose limitation, and in-country residency.
Data minimisation built in
Ingestion metering shows exactly what every service sends, so you can cut what you don't need instead of paying to store it.
Access that auditors accept
SSO with role mapping, RBAC across every surface, break-glass local login, and queryable history for alerts and access.
Four rules we won't trade for a demo.
These are taken verbatim from the engineering constraints in the codebase, not written for this page. They are the reason the product behaves predictably when it matters.
The store does the work
Anywhere a UI computes over a page of rows instead of the match set, the answer is wrong — not approximate. Aggregation belongs in the database.
Advisory means advisory
The assistant writes the RCA and the remediation plan; a human runs it. No auto-execution, not behind a flag. That's a product decision, not a missing feature.
Ambiguity gets an answer
A malformed or ambiguous question returns a clarifying response. A silent empty result set is the one answer we refuse to give.
No lock-in, structurally
Vendor-neutral instrumentation in, standard SQL across, open Parquet out. The exit path is part of the design, not a concession.
Built in three months. Here is exactly what shipped when.
Ten components, forty-one stories, delivered so that each month left the platform fully usable rather than half-wired. Click a phase to see what landed in it.
See it against your own telemetry.
A walkthrough runs 30 minutes: we point the platform at a service you pick, instrument it live, and ask it questions in plain English while you watch the SQL it writes.