SigNoz

What is SigNoz?

SigNoz is an open-source observability platform built on OpenTelemetry. It collects traces, metrics and logs in one place, giving you APM-style monitoring for your own services without per-gigabyte pricing from a vendor.

Best for

Teams that need tracing and monitoring on a predictable budget

Why choose SigNoz

SigNoz is what you reach for when you want the modern observability stack — traces, metrics and logs in one place, correlated, with an OpenTelemetry-native pipeline — without the per-host pricing of commercial platforms. It is built on the open standard for instrumentation, so adopting it does not lock your application code to a vendor, and because you run it, the retention window is a disk-space decision rather than a billing decision.

Replaces

• Datadog
• New Relic
• Grafana Cloud

Key features

• Traces, metrics and logs together
• OpenTelemetry native
• Service maps and alerts
• ClickHouse-backed storage

What to watch out for

It is a substantial deployment. The storage engine underneath is designed for analytical queries and wants real memory and fast disks; this is not a service that runs happily in 512 megabytes. Retention is the central operational question, because observability data grows relentlessly and a misconfigured window will fill a disk. As with any observability tool, the value is proportional to the instrumentation you add — install it and leave it empty and you have simply added another service to maintain.

How to deploy

• Docker Compose
• Kubernetes

Getting started

Give the host at least several gigabytes of memory and SSD storage before you install, and set a data retention period immediately rather than after the disk fills. Instrument one service with the OpenTelemetry SDK and confirm traces arrive end to end, since a broken collector pipeline looks exactly like an application that sends nothing. Configure alerting on one thing you genuinely care about — error rate or latency on a key endpoint — rather than against a list of defaults. Add logs last; getting traces right first makes everything else easier to interpret.

Typical setup

The deployment tends to be on a dedicated machine with SSD storage and several gigabytes of memory, since the analytical database behind it is not light. Applications send data via OpenTelemetry collectors, with a retention period set explicitly. Teams usually start by instrumenting one critical service, get traces flowing end to end, and only then add metrics and logs — doing all three at once tends to produce a dashboard nobody looks at.

Who should look elsewhere

Not appropriate for a single small server or a hobby project; the storage engine alone wants more memory than such a machine has. It is also the wrong investment if nobody will look at dashboards — observability only pays off when alerts are actioned, and an unread dashboard is simply an extra service to maintain and upgrade.

Project health

• GitHub stars: 32,253
• Last code push: 2026-10-01
• Open issues: 1,550
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.