Error tracking
Self-hosted, Sentry-compatible error tracking
Know about errors before your users report them.
Sentry-compatible error tracking, built in. Point your existing SDK at Temps and get stack traces, source maps, error grouping, regression detection, and real-time alerts — self-hosted, with no per-event pricing.
Every official Sentry SDK works, unmodified
Sentry-compatible error groups with events and timelines — the same view your existing SDK already talks to.
Key features
Your existing Sentry SDK just works
Temps injects SENTRY_DSN and SENTRY_RELEASE into every deploy automatically — keep the Sentry SDK you already have installed, no new library, no rewritten error-capture code.
Stack traces with source maps
Errors resolve to readable stack traces, not minified line numbers — source maps are handled the same way Sentry expects them.
Error grouping and regression detection
Related events collapse into a single issue, and a fixed error that comes back gets flagged as a regression instead of buried in a new group.
Real-time alerts to Slack or Discord
Your team hears about a new error the moment it happens, not the next time someone checks a dashboard.
Unlimited events, no per-event pricing
Self-hosted means there's no event quota to hit and no bill that grows with a bad deploy — the exact week you'd need it most.
Autofix: from error group to open PR
Click Fix on any error group and an AI agent reads your actual codebase, finds the root cause, and opens a pull request — gated on connecting a git provider, so it never runs against a repo you haven't authorized.
No dashboard step, no copy-pasted DSN
Temps sets the DSN and release for you.
Every deploy gets its own SENTRY_DSN — generated per project and environment — plus SENTRY_RELEASE, tagged automatically from the commit SHA or image digest you just deployed. Your Sentry SDK just reads the environment; there's no key to generate, copy, or store in your repo.
import * as Sentry from "@sentry/react"; // Temps injects a public, framework-specific DSN var at deploy time — // VITE_SENTRY_DSN for Vite-based apps (React, Vue, Remix, SolidStart), // NEXT_PUBLIC_SENTRY_DSN for Next.js. Sentry.init({ dsn: import.meta.env.VITE_SENTRY_DSN, });
Temps vs Sentry
Temps accepts events from the official Sentry SDKs, so the choice is about where errors go and what comes with them, not about rewriting instrumentation. Free to self-host, with no per-event pricing. The full Temps vs Sentry comparison goes feature by feature.
| Dimension | Temps | Sentry (cloud) | Self-hosted Sentry |
|---|---|---|---|
| SDK | Official Sentry SDKs, DSN pointed at Temps | Official Sentry SDKs | Official Sentry SDKs |
| Price | Free to self-host; you pay only for your server; no event quota | Free for 1 user and 5K errors; Team $26/month billed annually with 50K errors | Free |
| What you run | Nothing extra: it is part of the Temps install | Nothing: Sentry hosts it | Sentry's multi-service stack; documented minimum 4 CPU cores and 16 GB RAM plus 16 GB swap |
| Depth | Grouping, stack traces with source maps, regression and new-issue alerts | Profiling, release health, more advanced grouping | Sentry's Business-plan features, without Seer AI or billing features |
Sentry is the deeper error tracker. Temps' grouping is simpler, so issues Sentry would merge can appear separately, and historical events can't be imported from Sentry. The guide to error tracking without Sentry walks through the switch.
Competitor prices and plans verified on ; check each vendor's pricing page before you buy.
Questions
Further reading
Can I keep my existing Sentry SDK?
Yes. Temps exposes a Sentry-compatible DSN and injects SENTRY_DSN and SENTRY_RELEASE into every deployment, so the official Sentry SDK you already use keeps working. Moving is a DSN change, not a code change, and you can point the DSN back at Sentry at any time.
How is Temps different from self-hosted Sentry?
Self-hosted Sentry is the fuller error tracker, but it is its own multi-service stack with a documented minimum of 4 CPU cores and 16 GB of RAM plus 16 GB of swap. Temps' error tracking runs inside the Temps install next to deployments, analytics, session replay and uptime monitoring, with simpler grouping. Self-hosted Sentry is licensed under the FSL; Temps is MIT / Apache 2.0.
Is there an event limit?
No. Self-hosted Temps has no event quota and no per-event pricing; how many errors you keep is bounded by your server's disk.
What doesn't Temps' error tracking do?
It has no profiling or release health, and its grouping is simpler than Sentry's. Historical events don't migrate from Sentry, so run both side by side until you have the history you need.
Change one DSN. Keep your SDK.
Point your existing Sentry SDK at your own Temps instance — errors start flowing in immediately.
Try it yourself — quickstart guide