Open Source Sentry Alternatives

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.

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.

Error reports carry the same sensitive material as the application that produced them: user identifiers, email addresses, session tokens, whatever was in scope when the exception fired. Scrubbing all of that before shipping it to a third party is never finished work, and a missed field stays undetectable until it leaks. Bugsink keeps error tracking on hardware you control instead.

Your application reports through an SDK and Bugsink is the server that receives, groups, and displays what arrives. It is compatible with Sentry's open source SDKs, so connecting an existing project means changing a DSN rather than rewriting instrumentation. Evaluating it takes one docker run, after which the interface answers on port 8000.

The interface is arranged around the moment you actually need it, when something has broken in production.

• Stacktrace first: the full call stack sits at the top of the page rather than behind an expander.
• Local variables: the values held at the time of the error are shown alongside the code.
• Frame separation: in-app frames are distinguished from library frames so attention lands in the right place.
• Alerts: notifications fire on new issues, regressions, and issues whose mute period has expired.
• Smart retention: events are sampled by issue volume and age, so disks fill slowly instead of hitting a quota.

Published figures put throughput at 18 events per second on a two-core virtual machine with 4GB of memory, and the stress test scripts ship with the code so you can check that yourself. MySQL and PostgreSQL are both supported.

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.