Error Tracking and Uptime Monitoring for Small Teams, Without the Enterprise Bill
Sentry is priced by event volume, and event volume is not something you control on a bad day. Here is how the alternatives differ, what self-hosting really costs, and the four things to set up before you need any of them.
Quick answer
Error tracking and uptime monitoring are two different problems sold as one product, and small teams routinely overbuy on the first while neglecting the second. Sentry has the best SDKs and a bill that scales with your worst day rather than your traffic. GlitchTip speaks the same SDK protocol at a fraction of the cost and self-hosts in four containers instead of forty. Better Stack bundles errors, uptime and incident alerting at one price, which for a team of five is usually the right shape. Whichever you pick, sampling and a grouping rule matter more than the vendor: an unsampled error loop can turn a five-pound month into a four-hundred-pound one before anyone reads the email.
Most small teams buy error tracking twice. The first time is at launch, when someone signs up for the free tier and wires in the SDK. The second time is eight months later, when an unbounded retry loop generates two million events over a weekend and the invoice explains what event-based pricing means.
We have not load-tested these platforms against each other, and any article that claims to has usually tested the free tiers for an afternoon. What follows is how the pricing models differ, which decisions actually protect you, and where the cheap option is genuinely the right one.
Two problems sold as one product
Error tracking is your application reporting on itself. It catches the exception, attaches the stack trace and the request context, groups it with the other instances of the same fault, and tells you it is new or newly frequent. It is superb at this and structurally blind to one thing: it cannot report an error when the process is not running.
Uptime monitoring checks from outside. It has no idea what your code is doing and does not need to. It catches the expired certificate, the DNS record someone changed, the container that will not start, the deploy that took the site down entirely.
The outage that costs you a customer is nearly always the one only an external check would have seen. Teams that buy elaborate error tracking and skip a two-minute uptime check have optimised the wrong half.
Most vendors now sell both. The question is whether the second one is a real product or a checkbox, and the way to tell is whether it can alert you through a channel you will notice at three in the morning.
The bill scales with your worst day
This is the structural thing to understand about the category. You are billed by events, and events are not proportional to traffic. They are proportional to breakage.
A service handling steady traffic might generate a few thousand events a month. The same service with one endpoint failing in a retry loop can generate that in an hour. Pricing that looks generous at your normal volume is not the pricing that applies during the incident, and the incident is when you least want to be reading a billing page.
| Option | Free tier | Roughly | Best fit |
|---|---|---|---|
| Sentry | Modest monthly event allowance | Scales steeply with volume | Teams that need the deepest SDK and tracing support |
| GlitchTip | Around 1,000 events a month hosted | About $15 at 100k, $50 at 500k | Cost-sensitive teams already using Sentry SDKs |
| Better Stack | Around 100k exceptions a month | From roughly $29 a month | Teams wanting errors, uptime and on-call in one bill |
| Honeybadger | Trial rather than a standing free tier | Flat per-project pricing | Small teams that want one vendor and a predictable invoice |
The detail that makes this market unusually easy to move around in: GlitchTip and several others implement the Sentry SDK protocol. Switching is a configuration change rather than a rewrite. You do not have to get this right first time, which is a good reason not to spend a week on the decision.
What the alternatives actually change
GlitchTip is the lean option. It does error tracking, basic performance data and uptime checks, and it self-hosts in a handful of containers rather than the sprawling deployment a full Sentry installation requires. Its 2026 release improved stack trace handling noticeably. What you give up is the depth of Sentry's tracing and session replay features — which most teams of five were not using anyway.
Better Stack bundles errors with uptime monitoring and incident management, including on-call rotation and escalation. For a small team this shape is often right: the alternative is three subscriptions and three places to configure who gets woken up. It has also leaned into letting coding agents query exception data directly, which is either useful or a distraction depending on how your team works.
Honeybadger sells the same integrated idea with flat per-project pricing rather than per-event, which removes the incident-and-invoice problem entirely. If predictability is worth more to you than a low floor, that pricing model is the argument.
Self-hosting: the honest cost
Running GlitchTip yourself is realistic in a way that running Sentry yourself is not. It is a small application with a database and a queue, and it will sit happily on a modest virtual machine.
The costs are the ones you would expect and one you might not:
- It has to be up when everything else is down. An error tracker on the same host as the application it monitors is decoration. Put it somewhere else, or accept that it will be silent during exactly the failure you bought it for.
- Event volume becomes a disk problem. The retry loop that would have cost money on a hosted plan fills a disk instead. Set retention before you need it.
- It holds request data. Headers, parameters, sometimes bodies. That is personal data with obligations attached, and self-hosting moves those obligations onto you rather than away.
At small volumes the hosted plan usually costs less than the hours. The good reasons to self-host are wanting the data on your own hardware and having a contract that requires it — not the fifteen dollars.
Four things to set up on day one
These matter more than the vendor, and every one of them is skipped by teams that later describe their monitoring as useless.
1. A rate limit, before you need one
Cap events per hour at the SDK, not at the dashboard. A client-side cap is the difference between an incident and an incident plus a bill. Every major SDK supports this and almost nobody configures it.
2. Scrub the data going out
Default configurations capture more of the request than you would put in a log deliberately. Authorisation headers, session cookies, form fields, occasionally a whole request body. Set the denylist on the first day, because the entry you did not scrub is already stored by the time you notice it.
3. Two alert rules, not twelve
A new issue type in production, and an existing issue whose rate suddenly climbs. That is the whole useful set at a small scale. Every additional rule increases the odds the team mutes the channel, and a muted channel is worth less than no channel at all — it looks like coverage.
4. One external check that pages a human
A single request to a URL that exercises your database, every minute, from outside your infrastructure. If it fails twice in a row, someone's phone rings. This is the cheapest monitoring you will ever configure and it catches the failures the other three cannot see. If you set up nothing else on this list, set up this.
What we would pick at each size
- One person, a side project with real users: GlitchTip's hosted free tier plus a free external uptime check. Total cost nothing, and it covers the two failures that matter.
- Two to five people, a product people pay for: Better Stack, for the single bill covering errors, uptime and who gets woken up. The integration is worth more than the feature depth you are giving up.
- Five to twenty, with a real on-call rota: Sentry, honestly. The SDK depth and tracing start to earn the price once several people are debugging things they did not write — but set the spend cap and the sampling rate on the day you sign up.
- Regulated data or a contract that names where data lives: self-hosted GlitchTip, on infrastructure separate from the application, with retention configured before the first event arrives.
The pattern worth remembering is that this category punishes defaults. The default sampling rate, the default scrubbing rules and the default alert configuration are all tuned for a demo, and every one of them costs you something in production — money, privacy, or the team's willingness to look at the alerts. Half an hour of configuration on day one is worth more than any comparison table, ours included. If your stack is Postgres-backed, the query-level tooling we reach for covers the layer underneath this one.
Pros and cons
Pros
- A stack trace with the actual request state attached ends most debugging in minutes
- Sentry's SDK protocol is now a de facto standard, so switching vendors is cheap
- Free tiers cover a genuine small production workload, not just a demo
- Self-hosted options exist that are realistic to run, which was not true a few years ago
Cons
- Event-based pricing means an incident and an invoice arrive together
- Default alerting is noisy enough that teams mute it, which defeats the purpose
- Error trackers capture request data, and request data contains personal data
- Uptime monitoring is frequently an afterthought bolted onto an error product
Alternatives worth considering
The reference implementation. Best SDK coverage, priced by event volume.
Open source, Sentry-SDK compatible, hosted or self-hosted in a handful of containers.
Errors, uptime, logs and incident alerting bundled at one price.
Errors, uptime, cron checks and status pages from one vendor, aimed at small teams.
Frequently asked questions
Do we need error tracking if we already have logs?
Logs tell you what happened if you already know where to look. An error tracker tells you that something new started happening and how often, then groups every instance of it together so you see one issue rather than nine thousand lines. The two solve different problems. If you can only afford attention for one, the error tracker is the one that finds problems you did not know about.
How much sampling is too much?
For errors, sample as little as you can afford — the rare one is often the interesting one. For performance traces, sampling at a few per cent is normal and nobody notices the difference, because you are looking at distributions rather than individual requests. The pattern that gets teams in trouble is no sampling at all on a high-traffic endpoint that starts failing in a loop.
Is self-hosting worth it to save the subscription?
Only if you already run infrastructure and have a working backup routine. GlitchTip is genuinely light to run, but you are adding a service that has to stay up precisely when everything else is falling over, and one that holds request data you now have to secure. At a small team's volume the hosted plan is often cheaper than the hours. Self-host because you want the data on your own hardware, not to save fifteen dollars a month.
What is the difference between uptime monitoring and error tracking?
An error tracker sees what your application reports about itself, so it is blind to the failure where the application is not running at all. Uptime monitoring checks from outside, so it catches the expired certificate, the DNS change and the crashed process. The outage that embarrasses you is almost always the one only an outside check would have caught.
Written by
ToolNest Editorial
Editorial team
ToolNest's editorial byline. Our articles summarise and compare software using vendor documentation, changelogs, pricing pages and published reporting, and are drafted with AI assistance under human review. Where we have not used a tool ourselves, we say so rather than implying otherwise.