SigNoz: an OpenTelemetry-native observability platform you can self-host

The problem SigNoz takes on: three signals, three tools

Most teams end up with traces in one system, metrics in another and logs in a third, then spend the incident window moving between them. SigNoz's pitch is that those signals live in one platform, correlated by the same trace and span identifiers, so a slow service chart leads directly to the trace, then to the log line, without a context switch. The README frames this as an alternative to what it calls fragmented monitoring stacks.

The intended user is a platform or backend team that already instruments with OpenTelemetry and does not want to re-instrument for a vendor. The README states the platform is OpenTelemetry-native, which in practice means the ingest path is the OpenTelemetry collector rather than a proprietary agent. That matters if you have already paid the cost of adding the SDKs: switching backends becomes a configuration change on the collector, not a rewrite of application code.

SigNoz also covers ground beyond classic APM. The README lists trace funnels for request-flow drop-offs, LLM and AI observability for prompts, tool calls, token usage and cost, and infrastructure monitoring for Kubernetes pods and nodes. Those are separate product surfaces sharing one query layer, which is the actual argument for choosing it over assembling four tools.

How SigNoz stores and queries telemetry

The repository layout tells you most of the architecture. The backend is Go (go.mod declares go 1.25.7 and the module path github.com/SigNoz/signoz), the frontend is TypeScript and Next.js, and the storage dependency is ClickHouse: the module requires github.com/ClickHouse/clickhouse-go/v2 v2.44.0 and github.com/AfterShip/clickhouse-sql-parser v0.5.6. The README describes this as a single columnar database built for high-cardinality, high-volume observability workloads.

A single store for all three signals is the design decision everything else follows from. It is why the README can offer Query Builder, PromQL and ClickHouse SQL as three ways to build the same dashboard, and why log lines can be joined to traces without a cross-system lookup. The cost is that ClickHouse is not optional. There is no path where SigNoz runs against Postgres or object storage alone, so whoever operates the deployment owns ClickHouse capacity, schema and retention.

Ingest goes through the SigNoz OpenTelemetry collector, pinned in go.mod as github.com/SigNoz/signoz-otel-collector v0.144.6. The backend also pulls in github.com/open-telemetry/opamp-go, the Open Agent Management Protocol library, and the alerting path uses github.com/prometheus/alertmanager v0.31.1. Authorization uses github.com/openfga/api/proto, and the enterprise code sits in a separate ee/ directory with its own build targets in the Makefile (go-build-enterprise-amd64, go-build-enterprise-race-amd64), while the community binary builds from cmd/community.

Installing SigNoz and sending a first trace

The README does not inline install commands. It points to three deployment routes for the community edition: Docker, Kubernetes or Linux, documented at signoz.io/docs/install/self-host. Treat that page as the source of truth for the exact compose file and ports, because the repository does not pin them in the README itself.

The build side is visible in the Makefile, which is what you use if you are compiling from source rather than pulling images. The variables block declares the build context for the community binary as $(SRC)/cmd/community and the architecture list as amd64 arm64, so the community targets are named from those two values.

GO_BUILD_CONTEXT_COMMUNITY 		= $(SRC)/cmd/community
ARCHS					?= amd64 arm64

Those lines come from the Makefile's variable block. The community build targets are derived from them, and the enterprise targets build from cmd/enterprise instead.

Once the stack is up, the practical first test is whether your existing OpenTelemetry exporter can reach the collector. The repository files do not give a concrete endpoint or port for the self-hosted collector, so confirm the receiver address from the install documentation before changing application config. The README's instrumentation overview at signoz.io/docs/instrumentation/overview/ is the entry point it gives for wiring SDKs.

For agent workflows, the README points to the SigNoz MCP server documentation at signoz.io/docs/ai/signoz-mcp-server/ and to agent skills install instructions at signoz.io/docs/ai/agent-skills/#install-the-plugin. Note the boundary: Noz, the native AI teammate, is stated to be available only on SigNoz Cloud, not in the self-hosted community build.

Where SigNoz is the wrong tool

The clearest limitation is operational, not functional. Self-hosting SigNoz means self-hosting ClickHouse, and the README's own framing puts the free community edition in your infrastructure with full control of the data plane. Full control is also full responsibility: retention, disk growth and query performance on high-cardinality data are yours to manage. A team without someone who can size a columnar database should not start here.

The second boundary is the feature split between editions. The README places RBAC, ingestion controls, custom retention and data residency under Enterprise, and the AI teammate under Cloud. If your reason for evaluating SigNoz is the agent-native workflow, the community edition is not where that lives. Read the edition table before you spend a week on a proof of concept.

The licence field on the repository is NOASSERTION, which means GitHub could not map the LICENSE file to a known identifier. That is not the same as saying the project is unlicensed, but it does mean you cannot assume a standard permissive licence from the metadata alone. Open the LICENSE file and the ee/ directory before you build a commercial plan on top of it.

SigNoz versus Grafana: two different centres of gravity

The comparison people search for is SigNoz versus Grafana, and the difference is architectural rather than cosmetic. Grafana is a visualization and dashboarding layer that queries many backends; the data lives in Prometheus, Loki, Tempo or whatever else you connect. SigNoz ships its own storage and its own collector, so the query layer and the data layer are one product. The README's phrase for this is a single columnar database, and it is the reason SigNoz can correlate a trace to a log without you configuring a datasource relationship.

That choice cuts both ways. With Grafana you can keep existing Prometheus data and add SigNoz-style tracing later, or replace one component at a time. With SigNoz you adopt the stack. If you already run a healthy Prometheus and Loki setup and only lack trace correlation, adding Tempo to Grafana is a smaller change than migrating storage. If you are starting fresh and want one query surface, the SigNoz model avoids the datasource plumbing entirely.

A second alternative is the managed route within the same project: SigNoz Cloud, which the README describes as fully managed with a 30-day free trial, no credit card required, and usage-based pricing that starts at $49. Same query experience, no ClickHouse to operate. The trade-off is data residency and cost predictability, which is exactly what the self-hosted edition buys back.

Maintenance cadence, upgrades and licence questions

The release history is dense. v0.140.0 landed on 2026-09-02, v0.141.0 on 2026-09-09, v0.141.1 the same day, and the last push to main was on 2026-09-10. Version numbers in the 0.1xx range with patch releases hours apart suggest a fast-moving codebase where you should expect to upgrade on a schedule rather than once a year.

That cadence has a direct cost for self-hosters. The collector dependency is pinned to a specific version in go.mod, currently github.com/SigNoz/signoz-otel-collector v0.144.6, and the backend also depends on OpenTelemetry collector-contrib packages. Upgrading SigNoz can therefore move your ingest path, not just your UI. The repository does not document a rollback procedure, so plan a ClickHouse backup before you jump versions and check the CHANGELOG.md at the repository root for each release.

On licensing, the NOASSERTION signal plus the separate ee/ directory is the thing to verify. Enterprise code living in its own directory with its own build targets is a common pattern for mixed licensing, and the README separately markets Enterprise Cloud, BYOC and Enterprise Self-Hosted with compliance, support and RBAC. Whether the community binary you build from cmd/community carries obligations you can live with is a question for your own reading of LICENSE, not something the repository metadata answers.

Editorial conclusion

Adopt SigNoz if you already emit OpenTelemetry data and want traces, logs and metrics in one query surface that you control, and you are willing to run ClickHouse yourself. Skip it if you need a fully managed backend from day one, since the free tier is the self-hosted community build and the managed path is SigNoz Cloud with usage-based pricing. Before committing, check that the collector version in go.mod (github.com/SigNoz/signoz-otel-collector v0.144.6) matches what your applications already send.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. SigNoz/signoz on GitHub