Sentry uptime monitoring pricing and cron monitor cost, plan by plan

Team and Business include the same quotas on 13 of 14 rows

Sentry publishes a table called "A closer look at each plan" with fourteen rows across four plans. Read it row by row and the paid ladder does something almost no other vendor's does: the included amounts barely move. Team at $29 a month and Business at $89 include identical quantities of errors, logs, application metrics, trace spans, session replays, uptime monitors, cron monitors, attachments and build analyses. The one quota that changes is metric monitors, which goes from 20 to 1,000.

Business costs $648 a year more than Team on an annual contract, or $720 more on monthly billing. Divide that by the 980 extra metric monitors and you get about $0.66 per metric monitor per year, which is the entire capacity difference between Sentry's two paid plans. That is not a criticism, exactly. It is a statement about what you are buying: the upgrade is for features such as unlimited custom dashboards, advanced quota management and SAML with SCIM, and if you do not need those, Business gives you no extra headroom at all.

The comparison that surprised us more runs the other way. Take the free Developer plan and the $89 Business plan and put them side by side. Logs 5GB against 5GB. Application metrics 5GB against 5GB. Tracing 5M spans against 5M spans. Session replay 50 against 50. Attachments 1GB against 1GB. Size analysis 100 builds against 100 builds. Uptime monitors 1 against 1. Cron monitors 1 against 1. On eight of the metered rows, $1,068 a year of monthly billing buys exactly zero additional capacity. Across the whole ladder only two quotas ever rise, errors at the Developer to Team step and metric monitors at the Team to Business step, and each rises once.

Read that as a design decision rather than a trick and it makes sense. Sentry wants you on pay-as-you-go, where the meter runs on what you actually consume, instead of selling you a bigger bucket up front. It does mean that the usual instinct, upgrade the plan to get more room, does not work here. If you need more uptime monitors, the plan tier is irrelevant; the pay-as-you-go budget is the only lever, and Team is enough.

Sentry calls the same unit two different things, and we are not resolving it quietly

Inside a single cell of Sentry's plan table, the included allowance is written "1 uptime monitor" and the overage rate immediately below it is written "+$1.00/uptime alert additional". Monitor and alert are not the same unit. A monitor is a URL you watch; an alert is something that fires when the URL misbehaves. Bill per monitor and a flapping endpoint costs you a dollar a month. Bill per alert and the same endpoint could cost considerably more in a bad week.

The cron row directly beneath it says "+$0.78/monitor additional", using the same word in both halves, which is what makes the uptime wording look like a slip rather than a deliberate distinction. Sentry's help centre settles it in favour of the monitor reading: additional uptime monitors "cost $1/monitor/month". We publish the per-monitor figure on that basis and flag the pricing page's wording here rather than pretending the two surfaces agree.

This is the same posture we took on the unresolved $42 on the Uptrends breakdown and on Atlassian's reversed Opsgenie column headers. When a vendor's own documents disagree, saying so is more useful than picking the convenient number and hoping. If Sentry corrects the wording, this section will change with it.

What Sentry's uptime check actually does for the dollar

Price is the easy half. The harder question is whether a Sentry uptime monitor does the job you were going to give it, and here the documentation is specific enough to answer properly. Check intervals are 1, 5, 10, 20 or 30 minutes, or 1 hour. The methods available are GET, POST, HEAD, PUT, DELETE, PATCH and OPTIONS, with custom headers and a request body on the write methods. The timeout tops out at 30 seconds.

Two thresholds control when you hear about it. Failure tolerance defaults to three consecutive failures and recovery tolerance to one success. Sentry works the consequence out for you in its own documentation: "With a 5-minute interval and the default tolerance, an issue is created after 15 minutes of continuous downtime." That is the number to hold on to, because five minutes is the interval most people leave alone.

Credit where it is due on two points. Checks run from a variety of geographical locations in round-robin order, so consecutive failures come from different regions and a local network fault is less likely to page anyone at three in the morning. That is a genuinely sensible design and more than some dedicated monitoring vendors do. Sentry does not publish how many locations there are or where they are, so there is no figure to put beside anyone else's.

The second credit is the automatic setup: Sentry creates an uptime monitor for whichever hostname appears most often in your error data, so the free slot starts working without anyone configuring it. That is also worth knowing before you go looking for your one free monitor, because it may already be spent.

The real limitation is what counts as a pass. By default a check succeeds on any 2xx status code, which means a page that returns 200 while rendering a stack trace, an empty cart or a maintenance notice counts as up. Asserting anything more, a keyword in the body or a specific header, lives under a feature Sentry calls Verification, and Verification is restricted to the Early Adopter programme, which Sentry describes in its own documentation as "still in-progress and may have bugs". If your checkout page failing silently with a 200 is the scenario that actually worries you, that is the sentence that matters, not the dollar.

There is also no status page. The phrase does not appear anywhere on Sentry's pricing page, on any of the four plans, which is not a surprise for an error monitoring platform but does mean that telling customers about an outage is a separate purchase. We compared what that costs across vendors in the status page software breakdown.

Where these numbers come from, and one thing that nearly went wrong

Plan prices were read on 9 September 2026 from the schema.org Product block that sentry.io/pricing embeds as JSON-LD. It carries five priced entries: Developer at $0.00, Team monthly at $29, Team annual at $312, Business monthly at $89 and Business annual at $960.00, all in USD. Reading a machine-readable block beats parsing rendered cards, which is the same rule that made the Jira Service Management and PagerDuty breakdowns trustworthy. Enterprise carries no figure at all, so none is invented here.

The quota matrix needed more care. Flattening that table to text merges adjacent identical cells, and because so many of Sentry's rows repeat the same value across plans, the flattened version silently loses a column and makes the Developer plan look like the Team plan. The matrix above was parsed by DOM row instead, then validated against two rows whose answers were predictable: users must be 1 on Developer and unlimited on the paid plans, and metric monitors must differ somewhere. Both matched, so the parse was trusted. That is the same check that caught a bad feature count on Atlassian's page three days ago.

Geo-localisation was tested rather than assumed, because four vendors we have priced serve different lists to different countries. Refetching the identical URL with a German browser locale returned a byte-identical document, 1,116,242 bytes both times, with the same five USD figures and the same overage strings. There is no currency switcher and no second ladder, so a buyer in Chicago and one in Berlin see the same list. Sentry belongs with PagerDuty, Opsgenie, Pulsetic and Hyperping rather than with Uptrends, UptimeRobot, Site24x7 and Jira Service Management.

Not asserted anywhere on this page: Enterprise pricing, self-hosted Sentry, the Seer AI debugging subscription, reserved-volume discounts, and whether the annual discount reaches pay-as-you-go units. Where Sentry publishes no figure, none is guessed at.