Sentry's free plan is one of the better free tiers in developer tooling, and most people who hit its limits hit them by surprise. The plan is called Developer, it costs nothing, and its numbers are published. This post is those numbers read carefully, with the question that actually matters answered: what happens on the day you exceed them.
Everything about Sentry below is from their public pricing page at the time of writing. Their numbers change; check the page before you decide anything.
The Developer plan, as published
| Limit | Developer (free) |
|---|---|
| Price | $0 |
| Users | One |
| Errors | 5,000 per month |
| Logs | 5 GB |
| Tracing | 5 million spans |
| Session replays | 50 |
| Custom dashboards | 10 |
| Retention | 30-day lookback |
The two numbers that bite are the first two after the price.
One user. Not one project, one login. A second developer on the team cannot have their own account in the organization. In practice this means a shared login or a second organization, and either way the moment two people need to look at the same issue with their own accounts, you are on a paid plan.
5,000 errors a month. This sounds like a lot until you understand what an "error" is. It is one event: one occurrence of one exception. A single bug in a request handler on a site doing modest traffic can produce 5,000 events in an afternoon. A client-side error in a component that renders on every page can do it in an hour. The count is not "5,000 distinct problems," it is "5,000 times any problem happened."
What happens when you hit 5,000
Sentry meters events against the monthly quota. When the quota is used up, new events are not stored for the rest of the billing period unless you have set a pay-as-you-go budget on a paid plan. On the free plan, that means the rest of the month is dark: the SDK keeps sending, Sentry keeps discarding, and your issue list stops updating.
Three things make this worse than it sounds.
- It happens during the incident. Quota is consumed fastest exactly when something is broken. The bug that generates 5,000 events in an afternoon is the bug you most need to see, and it is the one that turns the lights off.
- The count you see is not the count that happened. After the quota trips, an issue that shows "312 events" may have had thousands more. The number on the screen is a floor, and nothing on the issue itself says so.
- The reset is on Sentry's calendar, not yours. If the quota trips on the 3rd, you wait until the next billing period.
Sentry publishes rate-limiting and sampling controls you can use to spend the quota more carefully, and they are worth setting up. They are also the moment the free tier stops being free of effort.
The next step: Team at $26 a month
The Team plan, as published, is $26 a month billed annually, unlimited users, 50,000 errors a month, 90-day lookback, and pay-as-you-go available for events beyond the included volume. Business is $80 a month with the same error volume and more dashboards and retention options. Enterprise is custom.
For a small team, Team is a reasonable price for a very good product, and the honest advice is that if you are already invested in Sentry's workflow and the one-user limit is the only thing in the way, $26 is not the thing to optimize. The event ceiling is the thing to understand: 50,000 a month is ten times the free tier, and a noisy client-side error can still get through it. Pay-as-you-go turns that from a dark month into an invoice, which is better, and which you should know is the trade.
How to know which plan you actually need
Before deciding, measure your own event rate for a normal week and for your last bad day. Two ways:
- Look at your current Sentry organization's stats page, if you have one, and find the peak day.
- If you have no error tracking yet, count 5xx responses and client-side exceptions in your logs for a week. Multiply the worst day by thirty for a pessimistic monthly figure.
If a normal month is under 3,000 events and the worst day is under 1,500, the free tier fits with room for a bad week. If either number is above that, plan for the tier you would be on during an incident, because that is when the count matters.
Once you have a number, put it into the Sentry pricing calculator: it takes a monthly event volume and the retention you need, and shows which published Sentry plan covers it, next to what the same numbers cost here. No signup, and every figure on it is dated.
An alternative with the count kept honest
RealUptime Errors is error tracking built around one rule: the count on the screen is never a lie. The free tier includes 10,000 events a month, twice Sentry's Developer plan, as a hard cap with no card. When the cap is reached, ingest stops, and every refused event is counted and shown as a number on the issue where you can see it, not in a footnote. You know the floor and you know the ceiling.
The rest of what you would expect is there: exceptions grouped into issues by fingerprint, tracking across releases so you can see which deploy introduced a problem and which one resolved it, JS/Node and Python SDKs, PII scrubbed by default, alerts when an issue is new or regresses.
And if you already have Sentry's SDK installed, you do not need to swap it. Point its DSN at RealUptime and keep the instrumentation you have. Migrating is a config change, and moving back is the same config change.
Paid tiers include 100,000 and 750,000 events, and pay for any two of Status, Monitor and Errors and all three are 20% off. The plan comparison is on the pricing page, and the side by side with Sentry is kept current with their published numbers, so you can check both against each other.
The short version
Sentry's free plan is good, and its two limits, one user and 5,000 events, are the ones that end it. Measure your event rate before you trust the free tier through an incident. If you want an error tracker that tells you the number it dropped instead of going quiet, start free on RealUptime Errors with 10,000 events and your existing SDK.