For most small teams, hosted Sentry is the right default, and the thing that decides whether it stays affordable is not the vendor but how many duplicate events your app emits. GlitchTip is a credible cheaper alternative if you only need error tracking and are happy with the Sentry SDKs. Self-hosting full Sentry is the option I would pick last, because the cost moves from a bill to your on-call time.
Why does the error quota run out in the first week?
The usual story: you add error tracking, everything looks calm, then a downstream API goes down for twenty minutes. A retry loop or a queue consumer throws the same exception on every attempt, and a plan priced by event volume absorbs thousands of identical events. The dashboard shows one issue with a huge count. The quota is gone and the useful errors that arrive afterwards are dropped or throttled.
Hosted tools price by events (or similar units) per month, and exact tiers change, so check the current pricing page rather than trusting a blog post. What does not change is the shape of the problem: volume is driven by your worst incident, not your normal day. A single noisy failure mode can cost more quota than a month of ordinary errors.
Takeaway: error-tracking cost is set by your noisiest incident, so cap duplicates in the client before comparing vendors.
Fix the volume first: client-side dedupe and sampling
Before you switch tools, drop repeats at the source. The Sentry JavaScript/Node SDK exposes beforeSend, ignoreErrors and sampleRate, and GlitchTip accepts events from the same SDKs, so this work carries over if you move.
import * as Sentry from "@sentry/node";
const WINDOW_MS = 60_000;
const MAX_PER_WINDOW = 5;
const seen = new Map<string, { count: number; start: number }>();
function fingerprintOf(event: Sentry.ErrorEvent): string {
const ex = event.exception?.values?.[0];
return `${ex?.type ?? "unknown"}:${ex?.value ?? ""}`;
}
Sentry.init({
dsn: process.env.SENTRY_DSN,
// Network noise you cannot act on
ignoreErrors: ["ECONNRESET", "AbortError"],
beforeSend(event) {
const key = fingerprintOf(event);
const now = Date.now();
const entry = seen.get(key);
if (!entry || now - entry.start > WINDOW_MS) {
seen.set(key, { count: 1, start: now });
return event;
}
entry.count += 1;
// Returning null drops the event before it counts against quota
return entry.count > MAX_PER_WINDOW ? null : event;
},
});
Two caveats from using this pattern. The Map grows with distinct messages, so if your error text embeds IDs you should key on the type and a normalized message, or add periodic cleanup. And a per-process limiter is per process: ten replicas each send their own five events per minute. That is still a large reduction from unbounded.
Hosted Sentry also offers server-side controls such as spike protection and inbound filters (as of late 2026 these are plan-dependent in places, so verify on your tier). Server-side filtering is a safety net, but dropping events in the client means they never reach the quota at all.
Takeaway: a ten-line beforeSend limiter removes the failure mode that makes every error-tracking plan look too small.
Sentry vs GlitchTip vs self-hosted Sentry: what actually differs?
| Hosted Sentry | GlitchTip (hosted or self-hosted) | Self-hosted Sentry | |
|---|---|---|---|
| SDK | Native Sentry SDKs | Sentry-compatible SDKs, change the DSN | Native Sentry SDKs |
| Scope | Errors, performance, session replay, profiling, more | Mostly error tracking, plus basic uptime and performance features | Broad, close to hosted feature set |
| Ops burden | None | Low: a small app plus Postgres and a queue | High: many services to run and upgrade |
| Cost driver | Event volume and add-ons | Hosted: plan tier; self-hosted: your server | Server size and your time |
| Main drawback | Quota anxiety, add-ons priced separately | Smaller feature set, smaller ecosystem | Upgrades and resource needs |
GlitchTip is open source, and because it speaks the Sentry ingestion protocol you can point an existing SDK at it by swapping the DSN. In my testing of that swap on a small Node service, errors, stack traces and breadcrumbs arrived without code changes. What you give up is breadth: if you rely on session replay, deep performance tracing or the newer AI-assisted triage features, expect gaps, and verify against GlitchTip's current docs before committing.
Self-hosted Sentry is the full product, but it runs as a large set of containers (databases, queues, ingestion workers and more) and its own docs describe a substantial minimum resource footprint. Upgrades are guided by an install script and are not a casual weekend task. For a team of two to five people, I have seen the hidden cost land as "nobody wants to own the upgrade", which is how an error tracker quietly stops working.
Takeaway: the SDK is portable across all three, so the real choice is how much of the platform you want to operate.
When is hosted Sentry worth paying for?
If you want one place for errors, performance traces and release health with no infrastructure, hosted Sentry is the product that covers all of that out of the box, and a paid plan is justified once errors are tied to revenue and someone is on call. The drawbacks are real: pricing is usage-based, so a bad incident can push you into overage or throttling, and optional features are billed separately.
If you only need "tell me when production throws and show me the stack trace", GlitchTip is the one that does that with the least overhead, and it is cheap or free to run on a server you already have. Its limitation is that anything beyond core error tracking is thinner than the original.
Self-hosted Sentry makes sense mainly when data residency or policy forbids a third-party SaaS and you have someone who will own upgrades.
Takeaway: pay for hosted Sentry when breadth matters, pick GlitchTip when errors are all you need, and self-host full Sentry only under a compliance constraint.
FAQ
Is GlitchTip compatible with the Sentry SDK?
Yes, GlitchTip accepts events from Sentry client SDKs, so you usually only change the DSN. Features beyond error ingestion, like replay, may not be available.
How do I stop one error from using my whole Sentry quota?
Drop repeats in the SDK with beforeSend and ignoreErrors, and use sampleRate for high-volume noise. Server-side spike protection helps, but client-side filtering keeps events from being counted at all.
Is self-hosting Sentry cheaper than the hosted plan?
Only if your time is free. The server cost is modest compared with the upgrade and maintenance effort of running a multi-service stack.
Bottom line
Start with hosted Sentry and a beforeSend limiter; most teams never need to leave. Move to GlitchTip if your bill is driven by volume and you only use error tracking. Self-host full Sentry only when policy forces it and an owner is named. Whatever you choose, test an incident: throw the same error 10,000 times in staging and see what the dashboard and your quota do.
Top comments (0)