Open Source Datadog Alternatives

Grafana lets you query, visualize, alert on and understand your metrics no matter where they are stored. Dashboards are made to be created, explored and shared with a team, which is how a data-driven habit spreads beyond the person who built the first panel.

Panels come from plugins, so the ways to show metrics and logs keep growing, and template variables turn a dashboard into a reusable one with dropdowns at the top. A data source is chosen per query, so a single graph can mix sources, custom ones included.

The daily surface is compact.

• Visualizations: fast client-side graphs with many options, extended by panel plugins.
• Dynamic dashboards: template variables that make one dashboard serve many teams or environments.
• Explore metrics: ad-hoc queries and drilldown, with split view comparing time ranges, queries and sources side by side.
• Explore logs: switch from metrics to logs with label filters preserved, then search or stream them live.
• Alerting: define rules visually and let Grafana evaluate them continuously, notifying Slack, PagerDuty, VictorOps or OpsGenie.

Installation guides cover the usual platforms, and a public play instance lets you try it before installing anything. Grafana is distributed under AGPL-3.0-only, with Apache-2.0 exceptions documented separately, and the contributor path includes a developer guide, a style guide and beginner-friendly issues.

Netdata came out of a failure nobody could explain, where cloud transactions broke silently and no monitoring tool had the resolution to show why. It collects every metric every second and discovers whatever runs on a node by itself, so setup is close to nothing.

The architecture keeps processing at the edge. The Agent handles collection, storage, machine learning, alerts and exports on each machine, while Netdata Cloud adds user management, roles and centralised alerting without pulling metrics into a central store.

A handful of design choices separate it from scrape-and-store metric stacks.

• Per-second collection: data lands and renders immediately rather than at a scrape interval.
• Anomaly detection: multiple unsupervised models are trained per metric on the node itself.
• Tiered storage: roughly half a byte per sample keeps long retention affordable on disk.
• Interactive dashboards: slice and filter the data without learning a query language first.
• Parent-child scaling: nodes centralise into parents handling millions of samples per second.

Coverage spans system resources, storage, network, sensors, processes, logs, containers, virtual machines and synthetic checks, fullest on Linux with FreeBSD, macOS and Windows supported to varying degrees. A University of Amsterdam study rated it the most energy-efficient tool for monitoring Docker-based systems.

Prometheus collects metrics from configured targets at given intervals, evaluates rule expressions against them, displays the results and triggers alerts when conditions are observed. It is a Cloud Native Computing Foundation project and a common base layer for infrastructure monitoring.

What sets it apart is a multi-dimensional data model, where a time series is identified by a metric name plus a set of key and value dimensions. PromQL exists to exploit that dimensionality, letting you slice series along labels instead of querying flat names.

Several architectural decisions shape how it gets deployed.

• Pull model: the server scrapes targets over HTTP rather than waiting for them to report.
• Autonomous nodes: a single server needs no distributed storage to stay useful.
• Service discovery: targets arrive from discovery mechanisms or from static configuration.
• Push gateway: batch jobs too short-lived to scrape push through an intermediary instead.
• Federation: hierarchical and horizontal federation links servers into larger topologies.

Installation runs from precompiled binaries, which the project recommends, or Docker images on Quay and Docker Hub. Building from source needs Go, NodeJS and npm, and the Makefile carries targets for building, testing, formatting and compiling the React interface, producing both the server and the promtool binary.

Users and logs provide clues, Sentry provides answers. The platform helps every developer detect, trace and fix issues in code that is already running, turning a vague report that something broke into the specific request and line that caused it.

Instrumentation happens through official SDKs, and the breadth of that list is the part that matters most when picking an error tracker. The project maintains more than twenty of them, each in its own repository with its own release cycle, so a polyglot estate reports into a single place.

The official SDKs span most environments where application code runs.

• Web and JavaScript: JavaScript, Electron and React Native reach browser, desktop and cross-platform mobile apps.
• Backend languages: Python, Ruby, PHP with a Laravel package, Go, Rust, Java and Kotlin, Elixir and Clojure.
• Apple and Microsoft stacks: Objective-C and Swift, C sharp and F sharp, plus PowerShell for scripting environments.
• Systems and cross-platform: a native C and C++ SDK alongside Dart and Flutter, and a Perl client.
• Game engines: Unity, Unreal Engine and Godot Engine each get a dedicated SDK.

Documentation, a bug tracker and GitHub discussions handle bugs, feature requests and general questions, while a Discord server hosts the wider community. The interface is translated through a public Transifex project anyone can join, and contributing guidelines for the platform itself live in the docs.

Most teams end up with a metrics system, a log store and a tracing tool that know nothing about each other, so debugging means carrying a timestamp between three browser tabs. SigNoz puts logs, metrics, traces, alerts, dashboards and exceptions in one product, so context travels with you instead of being reconstructed by hand.

It is built on OpenTelemetry, which means you instrument once with an open standard and keep ownership of the telemetry. Storage is a single columnar database chosen for high-cardinality, high-volume workloads, and queries can be written through a visual builder, PromQL or ClickHouse SQL.

The monitoring surfaces it ships with cover most of what a production team watches.

• APM: service latency, error rate, throughput, Apdex, top endpoints, database calls and external calls.
• Log management: ingest, search, aggregate and correlate logs against traces and metrics.
• Infrastructure monitoring: Kubernetes clusters, pods, nodes and workloads alongside host CPU, memory, disk and network.
• Distributed tracing: flamegraphs, waterfalls, span events and trace analytics, plus funnels that expose drop-offs in a request flow.
• LLM observability: traces for LLM apps and RAG pipelines covering prompts, tool calls, tokens, latency and cost.

The community edition is free and runs on your own infrastructure through Docker, Kubernetes or Linux, with managed cloud and enterprise tiers for teams that need compliance, RBAC, custom retention and support. An MCP server carries telemetry into coding agents for teams working that way.

OpenObserve gathers logs, metrics, traces, analytics, real user monitoring and AI observability into one platform, offered as an alternative to Datadog, Splunk and Elasticsearch for teams that cannot carry their cost.

Storage is Parquet columnar files on an S3-native design, which the project credits for storage costs up to 140 times lower than Elasticsearch. It is written in Rust and ships as a single binary that is running in under two minutes, with partitioning, indexing and caching cutting the search space for most queries.

The platform is organized around signals rather than separate tools.

• Logs: full-text search, SQL queries, quick filters and a visual query builder over log data.
• Tracing: OpenTelemetry-powered waterfalls, flame graphs and Gantt charts across services.
• Metrics and dashboards: query metrics with SQL or PromQL and build dashboards on any signal.
• Alerts and incidents: alerting and incident tracking sit inside the same interface.
• Multi-tenancy: organizations and streams are first-class concepts with complete data isolation.

A stateless architecture backed by object storage keeps recovery objectives low, and a high availability mode clusters for petabyte workloads. The core is AGPL-3.0, with super cluster federation and federated search across regions reserved for the enterprise edition.

VictoriaMetrics stores and queries time series data, most often as long-term storage for Prometheus or as a drop-in replacement for Prometheus and Graphite behind Grafana. It is optimized for the awkward case where old series are constantly retired and replaced by new ones at a high rate.

Two deployment shapes are open source under Apache 2.0: a single node and a cluster version. The single node has no dependencies, ships as one small binary, is configured through command-line flags, and the project argues it can stand in for medium-sized clusters built on Thanos, M3DB, Cortex, InfluxDB or TimescaleDB.

Ingestion and querying accept a wide spread of formats.

• Query languages: PromQL, and MetricsQL, the project's own faster dialect of it.
• Ingestion protocols: Prometheus remote write and exposition format, InfluxDB line protocol, Graphite, OpenTSDB, OpenTelemetry, DataDog, NewRelic, JSON, CSV and a native binary format.
• Stream aggregation: aggregate as data arrives, which lets it take the place of StatsD.
• Global query view: many Prometheus instances write into one store and are read with a single query.
• Operations: instant snapshots for backup and restore, metrics relabeling, a cardinality limiter and NFS-based storage such as Amazon EFS.

Published benchmarks claim up to seven times less RAM than Prometheus, Thanos or Cortex, and heavier compression than TimescaleDB, with Grammarly, Roblox, Wix and Spotify among the case studies. An enterprise edition adds anomaly detection, downsampling, multiple retentions and backup automation.

Quickwit is a search engine for observability data, logs and traces today with metrics on the roadmap. Its distinguishing decision is architectural. The index lives on cloud object storage and search runs against it directly, instead of against a fleet of stateful nodes holding local disks.

Getting there meant rebuilding the index data structures and IO paths. Compute and storage are decoupled, indexers and searchers are stateless, and queries return in under a second against Amazon S3, Azure Blob Storage or Google Cloud Storage. The project estimates this runs up to ten times cheaper than Elastic.

Compatibility is where Quickwit tries hardest to be undisruptive.

• Elasticsearch API: a large subset of the query DSL, endpoints and aggregations, usable from existing clients.
• OTEL native: OpenTelemetry ingestion for both logs and traces with no translation layer in front.
• Jaeger native: traces plug straight into Jaeger for distributed tracing workflows.
• Grafana data source: a dedicated plugin for querying Quickwit from existing dashboards.
• Schemaless or strict: index without declaring a schema or enforce one, with schemaless analytics either way.

Operationally it ingests natively from Kafka, Kinesis and Pulsar, supports multi-tenancy through many indexes and partitioning, applies retention policies, and runs delete tasks for GDPR requests. A Helm chart covers Kubernetes and everything is reachable over a REST API.

Migrating off Elasticsearch or OpenSearch is eased by an ES-compatible ingest API, so shippers such as Vector, Fluent Bit and Syslog keep working. A client that balks at a version check is satisfied with extra headers in the node configuration.

HyperDX helps engineers work out why production broke by making logs and traces searchable on top of any ClickHouse cluster. Think of it as Kibana pointed at ClickHouse, and it reads whatever schema is already there instead of demanding a new one.

It is a core component of ClickStack, which bundles ClickHouse, HyperDX, an OpenTelemetry collector, and MongoDB. One Docker command brings the whole set up and serves the interface on port 8080, while teams with an existing ClickHouse instance or a ClickHouse Cloud account can point HyperDX at that instead.

Searching is built for people who do not want to write SQL under pressure.

• Property search: full-text search alongside a short property syntax such as level:err, with SQL optional.
• Correlated signals: logs, metrics, session replays, and traces are searched and viewed in one place.
• Live tail: logs and traces stream in, so the freshest events are always on screen.
• Event deltas: anomalies are compared against normal traffic to show what actually changed.
• Alerts and dashboards: alerts take a few clicks, and high cardinality events chart without a query language.
• Terminal client: an hdx CLI offers a TUI with vim-style keys, ANSI charts, NDJSON output, and Drain pattern mining.

Instrumentation goes through OpenTelemetry, covering Kubernetes, JavaScript, Python, Java, Go, Ruby, PHP, .NET, Elixir, and Rust, with the collector listening on port 4318. Testing wants at least 4 GB of RAM and two cores. Code contributions now use a vouching model, where a maintainer sponsors a newcomer before a first pull request is reviewed.

Bug reports rarely explain themselves. highlight.io closes that gap by pairing every error with the recorded session that produced it, an open source fullstack monitoring platform covering session replay, error monitoring, logging and traces.

Installation is meant to be a few lines of code in any environment, using the client and server SDKs that ship in the repository. Session replay is powered by rrweb, and the same instrumentation feeds errors, logs and traces, so each signal links back to the others instead of living in a separate tool.

The product groups its work into connected surfaces.

• Session replay: replays every interaction and DOM change in a browser session, with the network requests and console output alongside.
• Error monitoring: groups repeated errors under rules you customize and links each one to the sessions where it happened.
• Logging: searches across server logs with automatic property collection and threshold based alerts.
• Tracing: measures the performance of server operations, correlated with the sessions, errors and logs around them.
• Comments: let teammates annotate a session so bugs and user frustration get discussed in place.

A hobby instance deploys in one line with Docker on Linux, and the maintainers suggest at least 8 GB of memory, four CPUs and 64 GB of disk. That tier fits under 10,000 sessions and 50,000 errors ingested monthly; heavier installs follow the enterprise self-hosting path, and a hosted version exists for teams who would rather not run it themselves.

Collecting metrics, logs and traces does not by itself make a system observable. Coroot gathers that data and turns it into findings, so an engineer reads a verdict rather than assembling one from a wall of dashboards.

Collection runs on eBPF, so metrics, logs, traces and profiles arrive with no code changes, including from legacy or third-party services nobody can instrument. The result is a service map covering the whole system, with predefined inspections auditing each application without configuration. Log search is backed by ClickHouse, and tracing stays vendor neutral through OpenTelemetry.

Coroot organizes what it finds into a few working views.

• Health summary: shows the status of hundreds of services at once and tracks service level objectives.
• Distributed tracing: opens any outlier request in a single click for investigation.
• Log patterns: cluster events out of the box and correlate logs with the traces behind them.
• Continuous profiling: attributes a CPU or memory spike to the precise line of code, compared against baseline behavior.
• Deployment tracking: discovers every rollout in a Kubernetes cluster and compares each release with the previous one, with no CI/CD integration.
• Cost monitoring: attributes AWS, GCP and Azure spend down to a specific application without access to your cloud account.

The project states that its built-in inspections identify over 80 percent of issues automatically, and an application missing its objectives triggers one alert carrying every relevant inspection. Coroot runs as a Docker container or in any Kubernetes cluster under the Apache 2.0 license, with an enterprise edition alongside.

OneUptime brings monitoring, alerting, incident response and observability into one application, so a team stops paying for a dozen products and stitching them together. It catches the outage, pages the right person, updates the status page and helps find the cause.

The platform maps directly onto the tools it displaces. Uptime monitoring covers website, API, ping, port, SSL, DNS and synthetic checks from probes around the world, while APM, metrics, log management and error tracking handle what happens once an alert has fired.

A single incident runs end to end inside the product.

• Detect: regional probes open an incident automatically when a threshold is crossed.
• Respond: on-call schedules and escalation policies call, text and push until someone acknowledges.
• Communicate: branded public and private status pages update themselves and notify subscribers by email and SMS.
• Diagnose: traces, logs and metrics correlate down to the individual span behind a slowdown.
• Auto-fix: an AI agent opens a pull request linked to the incident, verified against your configured build and test commands before you review it.

All of it is Apache 2.0 licensed. Self-hosting runs on a single Debian, Ubuntu or RHEL server with Docker and Docker Compose, cloning the release branch and filling a config file with your own strong secrets, and a Helm chart covers Kubernetes. A hosted cloud with a free tier funds the open source work for teams that would rather not operate it.

Three observability signals usually mean three backends, three query languages and no way to join across them. GreptimeDB puts metrics, logs and traces on a single columnar engine over object storage, sharing one table model of tags, timestamp and fields, so signals sharing a service, host or trace identifier correlate in SQL.

Compute and storage are disaggregated. Object storage on S3, GCS, Azure Blob or an S3-compatible endpoint holds the data, while memory and local disk caches keep recent and frequently queried rows near compute. A standalone binary suits development, and the distributed mode splits into frontend, datanode, metasrv and an optional flownode for streaming computation.

Migration can move one signal at a time rather than all at once.

• Ingestion: OpenTelemetry, Prometheus Remote Write, Loki Push, Elasticsearch bulk, InfluxDB line protocol and gRPC.
• Query: SQL and PromQL, Jaeger-compatible trace queries, and the MySQL and PostgreSQL wire protocols.
• Built in: retention policies, downsampling, continuous aggregation, explicit table partitioning and inverted, skipping and fulltext indexes.
• Compatibility limits: LogQL and most Elasticsearch APIs are not covered, and PromQL has documented gaps.
• Edition boundary: read replicas, workload isolation and automated repartitioning belong to the commercial Enterprise build.

The Apache-2.0 core includes cluster deployment, object storage, the flow engine and every ingestion protocol listed above, though repartitioning, region migration and index creation are manual. A Docker image starts a standalone instance with a dashboard on port 4000, and building from source needs a nightly Rust toolchain, protobuf 3.15 or later and C and C++ build essentials.

Zabbix watches the availability and performance of an entire IT estate from one place, from a single standalone application up to a large environment spread across data centers. It replaces the pile of per-device checks and ad hoc scripts that accumulate around infrastructure over time.

Metrics arrive with or without an agent, from devices, sensors, operating systems, virtualization and container platforms such as Docker and Kubernetes, cloud infrastructures, databases, web pages, Java ecosystems, API endpoints and business applications. Ready-made templates cover integrations from a low-level device up to a SaaS service.

The rest of the platform turns those metrics into action.

• Resource discovery: find network entities and server resources, then onboard or offboard devices.
• Root cause analysis: detect problems in real time and correlate existing ones with incoming ones.
• Alerts and notifications: reach people through Slack, Jira, Microsoft Teams, email or text messages.
• Visualization: read collected data in graphs, lists, geomaps and network topology maps.
• Multitenancy: run one instance for several data centers, departments or organizations.

Remote locations behind firewalls are covered with remote command execution, and built-in functions handle reporting, auditing, security and service SLA calculations, with metrics and events streamed over HTTP. Zabbix is distributed under AGPL-3.0-only, with downloads and an installation manual published for self-hosted deployment.

From the team behind Pydantic Validation, Logfire is an observability platform built on the same belief as that library, that a tool doing serious work can still be easy to use. This repository holds the Python SDK and the documentation.

Logfire is an opinionated wrapper around OpenTelemetry with full support for traces, metrics and logs, so existing OTel tooling, infrastructure and instrumentation keep working and the SDK can export to any OTel-compatible backend. Getting started is a pip install and an auth command, after which you write manual spans or instrument a package such as FastAPI in one call.

What sets it apart is a lean toward Python and SQL.

• Python-centric insights: rich display of Python objects, event-loop telemetry, and profiling of Python code and database queries.
• Standard SQL: query your data with SQL, which also opens it to existing BI tools and database libraries.
• Pydantic integration: see the data flowing through your validation models, with built-in analytics on validations.
• Dashboard: kept simple relative to what it exposes, on the theory that a team only uses a tool it can read.
• Other languages: SDKs exist for TypeScript and Rust, and the OpenTelemetry foundation extends support to virtually any language.

One boundary is worth knowing before adopting it. The SDKs are open source, but the server application that records and displays the data is closed source, and self-hosting that platform requires buying an enterprise license. The documentation also covers what Logfire does for LLM apps and agents, and for running evaluations in production.

Uptrace is an open source APM covering distributed tracing, metrics and logs behind a single interface. Instead of running a separate system for each signal, you send everything through OpenTelemetry and query it from one place, with a query builder, dashboards and alerting on top.

Storage is ClickHouse, with PostgreSQL holding metadata such as metric names and alert definitions. That pairing is where the cost argument comes from: a one kilobyte span compresses to roughly forty bytes on disk, a single core processes more than ten thousand spans per second, and one server can carry billions of spans and metrics.

Querying and alerting are built around shapes engineers already know.

• SQL-like span queries: spans and logs are aggregated with a language close to SQL.
• PromQL-like metric queries: metrics use a syntax Prometheus users will recognize.
• Prebuilt dashboards: more than fifty dashboards appear automatically once matching metrics start arriving.
• Alerting: rules over spans, logs and metrics notify by email, Slack, webhook or AlertManager.
• Grafana compatibility: Uptrace can be configured as a Tempo or Prometheus data source.

Ingestion accepts OpenTelemetry, Prometheus, Vector, FluentBit and CloudWatch among others, and a service graph plus chart annotations tie deploys to what the charts show. Users and projects are managed from a YAML config, and single sign-on works over OpenID Connect with Keycloak, Google Cloud and Cloudflare. A cloud demo needs no login, and a Docker example gets a local instance running quickly.

Checkmk monitors infrastructure and applications across physical, virtual, containerized and cloud environments. It is designed for scalability, flexibility and low resource consumption, which matters once a single server has to watch thousands of hosts without becoming the heaviest thing on the network.

Checkmk Community is the free and open source edition under the GNU GPL v2. It carries the monitoring core, a web-based interface, agent-based and agentless monitoring, and hundreds of official and community-maintained plugins, which fits smaller environments with modest automation, dashboarding and support requirements.

The commercial editions extend that base in specific directions.

• Pro: distributed monitoring, built-in dashboards, automated agent management and enterprise integrations such as LDAP and REST APIs.
• Ultimate: everything in Pro plus Kubernetes, AWS, Azure and GCP coverage, application metrics over OpenTelemetry, push agents and host auto-registration.
• Cloud: the SaaS version, with automatic updates, backups and no infrastructure to run yourself.
• Multi-tenancy: an Ultimate variant for managed service providers, adding centralized monitoring of many customer environments, isolated access controls and MSP reporting.
• Free trials: evaluation downloads of the paid editions, so nobody has to buy blind.

Installation uses DEB and RPM packages on RedHat and its derivatives, Ubuntu and SUSE Linux Enterprise Server, generally the stable or long-term releases. Every edition also runs as a Docker container, and Pro and Ultimate ship as virtual or physical appliances. Building your own packages is possible, though the prebuilt ones are what the project recommends.

Icinga 2 watches whether the machines and services on a network are actually up, tells the right people when they are not, and records performance data that reporting can be built on. It is aimed at environments too large or too scattered for a single check host to cover.

Icinga 2 is the monitoring server, and a working stack pairs it with Icinga Web 2 for the interface. Configuration is plain text written in the Icinga DSL, or managed through the Icinga Director or a configuration management tool. Distributed setups spread checks across multiple locations, so a data center and private, public or hybrid clouds are watched from one system.

The documentation covers the pieces an operator assembles around the server.

• Packages: builds for Debian, Ubuntu, Raspberry Pi OS, Fedora, RHEL, OpenSUSE, SLES, Amazon Linux, Windows and containers.
• Agent based monitoring: run checks on the monitored host itself rather than only from the server.
• REST API: query state and drive the running configuration programmatically.
• Template library: reuse the bundled check command definitions instead of writing each one.
• Modules: extend the stack with the many add-ons and integrations built around Icinga.

Licensing changed at version 2.16.0, where new releases moved to GPLv3 or later while every earlier version and existing source file stays GPLv2 or later, with an OpenSSL linking exception that matters only for OpenSSL 1.x. Community channels handle questions, Icinga partners sell professional support, and the upgrading chapter is worth reading before any major version jump.

Maple collects traces, logs, and metrics through OpenTelemetry and stores them in ClickHouse. The point is a single place to look when a request goes wrong, without the instrumentation being tied to a vendor that owns the query language it is read with.

The repository is a Bun monorepo. A TanStack Router single-page application serves the dashboard, an Effect-based HTTP API sits behind it carrying an MCP server and AI triage, a separate OTLP ingest gateway handles key authentication and organization enrichment before forwarding to a collector, and an alerting worker evaluates rules on a cron schedule. Shared packages hold the HTTP contracts, the query engine, and UI primitives, while application state lives in PostgreSQL.

The choices to make up front are how it runs and how people sign in.

• Local binary: a Homebrew install and one start command bring up OTLP ingest, embedded ClickHouse, and the dashboard together.
• Docker Compose: the multi-service stack of API, web, ingest, and OTEL collector on local ports.
• Cloudflare Workers: deployment through Alchemy, with PlanetScale Postgres reached over Hyperdrive.
• Clerk auth: organizations come from a Clerk application, with optional networkless token verification.
• Self-hosted auth: a single root password issues bearer sessions valid for twelve hours, capped at seven days from sign-in.

Ingest keys are managed per organization and can be rerolled independently, with private keys encrypted at rest and looked up through non-reversible HMAC hashes. Bun 1.3 or later is the only prerequisite for the code, and a native SwiftUI iOS client lives in the same repository.

Nagios Core watches hosts, services, and networks, telling you when something breaks and again when it recovers. It has done that since 1999, written in C under version 2 of the GNU General Public License, which is a large part of why so much monitoring tooling still speaks its plugin format.

Checks are external programs. The core schedules them, reads their exit status, and acts on the result, so a new kind of check means writing a small program rather than extending the daemon. Hosts form a hierarchy through parent relationships, which lets the software distinguish a host that is down from one merely unreachable behind a failed router. CGI programs bundled with the release provide the optional web interface.

The functionality has held the same shape for a long time.

• Service checks: network services monitored over SMTP, POP3, HTTP, PING, and more.
• Host resources: processor load, disk usage, and similar local measurements.
• Plugin interface: user-developed monitoring methods plug in without touching the core.
• Parent hosts: a hierarchy that separates down from unreachable.
• Notifications: alerts on problem and recovery by email, pager, or a method you define.
• Event handlers: commands run automatically to attempt resolution before a person is paged.
• Web interface: current status, notification and problem history, and log files in a browser.

Log files rotate and archive on their own. Quickstart guides, a user guide, and a documentation library are published alongside the releases, support runs through community forums, and security issues go to a dedicated address, not the public tracker.

Running Loki, Prometheus, Tempo and Pyroscope separately means four storage layers and four operational stories. Gigapipe, formerly known as qryn, implements all four sets of APIs itself, so logs, metrics, traces and profiles land in one lightweight stack that existing clients already know how to talk to.

Ingestion is deliberately promiscuous. OpenTelemetry is officially integrated and needs no changes to your instrumentation, while native ingestion also covers Loki, Prometheus, Tempo, Zipkin, Pyroscope, Influx, Datadog and Elastic. Storage sits on ClickHouse, DuckDB or GigAPI with S3 object storage, so the data stays under your control.

Querying works through the languages people already use.

• LogQL: the Loki API is implemented, so any Loki client or the Grafana Loki datasource works with no plugin.
• PromQL: Prometheus API compatibility is provided using WASM.
• TraceQL: Tempo query support covers traces alongside the other signals.
• Profiling API: profiling endpoints export DOT format for Graphviz, and OTLP profiles are ingested through a development endpoint.
• Index stats and tail: stream metadata queries return stream, entry, byte and chunk counts, and live tail takes limit and start parameters and reports dropped entries.

A built-in explorer and a CLI cover people without Grafana, and an OTLP over gRPC receiver takes traces, logs, metrics and profiles. Configuration, a Docker quickstart and cross-cluster setup are documented in the repository. Gigapipe presents itself as the community-powered alternative to vendor-controlled observability stacks, with a hosted free trial for anyone who wants to test before installing. Contributions require a CLA.

Running a small product usually means paying for a deployment platform, an error tracker, an analytics service, an uptime monitor, an email sender, and a sandbox provider, then stitching six dashboards together. Temps collapses that into one self-hosted install deployed with a single shell command.

Git push builds and deploys any language it auto-detects, or your own Dockerfile, with preview links and zero-downtime rollouts, and it provisions Postgres, Redis, MinIO, and MongoDB alongside your apps. The proxy runs on Cloudflare's Pingora engine with automatic TLS from Let's Encrypt. If you already run Coolify, Dokploy, CapRover, or Portainer, an import wizard carries over apps, databases with their data, domains, and variables.

Observability and the AI surfaces are built in rather than bolted on.

• Error tracking: point the official Sentry SDK at a Temps DSN for error groups, stack traces, and alerts without per-event pricing.
• Analytics: visitor tracking, funnels, and rrweb session replay, with nothing leaving your servers.
• OpenTelemetry: any OTLP exporter feeds traces, metrics, and structured logs into one place, with no Grafana, Prometheus, Jaeger, or Loki to run.
• AI gateway: bring your own keys for OpenAI, Anthropic, Google, and xAI behind one OpenAI-compatible endpoint with per-request cost attribution.
• Sandboxes: Firecracker microVMs or Docker isolate agent-generated code, with password-protected preview links.
• Agent control: more than 440 CLI operations across 69 groups, plus skills that teach Claude Code, Codex, or OpenCode to drive them.

Uptime monitors and alerting round it out, and the built-in chat answers from your own telemetry, read-only unless you opt into writes.