Introduction

Sophonz starts instrumentation in the browser and the mobile app and carries the same trace through to your backend, on OpenTelemetry.

Observability that starts at the front end

Observability products usually start at the server. Browsers and mobile apps arrive later as a separate RUM product with a data model of its own, which leaves someone joining "slow screen" to "slow query" by hand.

Sophonz runs the other way round.

• Front-end SDKs are first-class. Web, Android, iOS, Flutter, and React Native, each emitting session replay, Web Vitals, errors and crashes, and user events as OpenTelemetry signals.
• One trace from screen to query. The browser SDK attaches traceparent to outgoing requests, so the button press, the handler that served it, and the database call it made all sit on one trace. Nothing has to be correlated across two tools.
• No RUM-only format. Front-end data uses the OpenTelemetry semantic conventions — Web Vitals go out as browser.web_vital, for instance — so it answers to the same queries as your backend telemetry.
• No proprietary agent, no lock-in. Instrument once and keep ownership of your telemetry.

What you can solve

Once your app is instrumented with OpenTelemetry, every request emits traces, metrics, and logs with context propagated end-to-end. The OpenTelemetry Collector refines that data and the Sophonz Observability Engine stores, queries, and correlates it — pinpointing the exact point of failure through distributed tracing, error and crash reports, app performance, and real-user sessions. From there the Sophonz AI Engine fixes the code, opens issues and PRs, and suggests UI improvements; the improved app then ships and re-emits telemetry, closing the loop.

How it works

Telemetry flows from your apps and infrastructure through the OpenTelemetry Collector into ClickHouse, where the Sophonz engines power monitoring and an AI automation pipeline that loops fixes back into your services.

Built on OpenTelemetry

Sophonz is built on OpenTelemetry — the open source, vendor-neutral observability framework for cloud-native software. Instrument your code once and keep full ownership of your telemetry.

Observability signals

• Traces — distributed traces across services
• Metrics — measurements over time
• Logs — timestamped records
• Baggage — contextual metadata that travels with the request

What OpenTelemetry brings

• Vendor-neutral instrumentation — instrument once with OTel APIs and SDKs, export to any backend (Jaeger, Prometheus, a commercial vendor, or your own), and switch backends without touching app code.
• Unified signals — traces, metrics, and logs correlated through shared context across the whole request path.
• Auto-instrumentation — zero-code instrumentation for popular frameworks and libraries.
• Collector pipeline — receive, process, filter, and route telemetry at scale with 200+ components.
• Context propagation — correlate traces across service boundaries into one unified view.
• Multi-language support — native SDKs for 12+ languages: Java, Kotlin, Python, Go, JavaScript, .NET, Ruby, PHP, Rust, C++, Swift, and Erlang.
• Stable and production-ready — stable tracing and metrics APIs, run by thousands of organizations in production, backed by the CNCF.
• Open specifications — open APIs, SDKs, and the OTLP wire protocol under transparent CNCF governance.
• Run anywhere — 100% open source; deploy on-prem, hybrid, or multi-cloud with zero lock-in.

SDK setup

You install a platform SDK, point it at your collector endpoint, and Sophonz takes care of capturing telemetry and forwarding it to your backend of choice.

import { SophonzSDK } from "@sophonz/browser-sdk";
 
const sophonz = SophonzSDK.init({
  endpoint: "https://in.sophonz.ai",
  appName: "my-app",
});

Next steps

Continue with the Quick Start to wire Sophonz into your project, then read the Best Practices before going to production.