Sentry added uptime checks to its platform: point it at a URL, pick an interval, and it polls that URL on a schedule the same way a dedicated uptime tool would. Three failures in a row and it opens an issue, the same place your error tracking already lives. The appeal is obvious if you're already in Sentry for exceptions: one less dashboard, one less bill to think about.
The parts worth knowing before you flip it on are what you actually get on each plan, what it costs once you're watching more than one thing, and where the alert ends up landing.
What is Sentry Uptime Monitoring?
It's an outside-in HTTP check. Sentry's servers request a URL you specify from "a variety of geographical locations in a round-robin fashion," wait for a response, and judge the result against a timeout (up to 30 seconds). It can also auto-detect a candidate: Sentry will offer to turn the most frequently seen hostname in your existing error data into a monitor, so if you already send errors from api.yourapp.com, it'll suggest watching that host without you typing a URL in by hand.
This sits next to, not instead of, Sentry's error and performance tooling. A downed service doesn't just fail silently somewhere in a separate tool; the outage issue shows up alongside whatever exceptions it's throwing.
How do you set up an uptime monitor in Sentry?
You create it from the Monitors page, either manually or by accepting the auto-detected suggestion. The fields you configure:
- URL: the target Sentry will check.
- HTTP method: GET, POST, HEAD, PUT, DELETE, PATCH, or OPTIONS.
- Headers: custom headers on top of the User-Agent and Sentry-Trace headers Sentry adds automatically. (Sentry's own docs warn not to put API tokens or anything sensitive in them, since a monitor's config isn't a secrets store.)
- Body: a request payload, available when the method is POST, PUT, or PATCH.
- Interval: 1 minute, 5 minutes, 10 minutes, 20 minutes, 30 minutes, or 1 hour.
- Timeout: how long Sentry waits for a response before marking the check failed, up to 30 seconds.
There's also an early-access verification option that lets you assert on the response, status codes, headers, or a JSON body, and test the assertion before saving the monitor.
Two thresholds decide when a check-in state actually flips into an issue:
- Failure tolerance: defaults to 3 consecutive failures before an outage issue opens.
- Recovery tolerance: defaults to 1 consecutive success before it's marked recovered.
None of that requires an SDK in your application. It's a server-side poller you point at a public or reachable URL, closer to a classic uptime checker than to Sentry's error-tracking SDK integrations.
How does Sentry decide a site is down?
By counting consecutive failed checks against the failure tolerance above. At the default settings and a 5-minute interval, that's roughly 15 minutes of continuous failure before an issue opens, since nothing fires until the third bad check in a row lands. Drop the interval to 1 minute and that window shrinks to about 3 minutes; stretch it to the 1-hour interval and a real outage could run most of 3 hours before Sentry says anything, if you leave the default tolerance in place. The interval and the failure tolerance aren't independent choices: a slow interval with the default tolerance is a long time to be quietly down.
Alerting itself isn't automatic once an issue opens. You still have to "configure an Alert that matches outage / downtime issues and add actions for email, Slack, on-call tools, or other integrations." Uptime monitoring creates the issue; a separate alert rule decides who hears about it and where.
How much does Sentry Uptime Monitoring cost?
Every plan, including the free tier, includes exactly one uptime monitor. Beyond that, Sentry's pricing page lists the overage as "+$1.00/uptime alert additional" per month, on top of whatever you're already paying for errors, spans, and replays.
The plans themselves, billed annually:
- Developer: free. 1 uptime monitor, 5k errors, 5M spans, 50 replays.
- Team: $26/month. 1 uptime monitor, 50k errors, 5M spans, 50 replays.
- Business: $80/month. 1 uptime monitor, 50k errors, 5M spans, 50 replays.
- Enterprise: custom.
The number that catches people is that the included monitor count doesn't scale with the plan. Team and Business both still ship with one. If you run a web app and an API behind an iOS app, as plenty of indie stacks do, that's already two monitors, meaning one of them is paying the $1/month overage the moment you add it, on any plan including the free one.
When is Sentry Uptime Monitoring the right tool?
Stay with it, or turn it on, when the thing you actually want is the issue correlation:
- You already run Sentry for errors. An outage issue sits in the same stream as your exceptions, so a 500 spike and the "this URL stopped responding" issue are easy to connect by eye.
- You want one alert pipeline, not two. If your on-call already watches Sentry issues and your alert rules are already built out there, routing uptime through the same rules means no second integration to wire up.
- Your check count is genuinely small. One app, one URL, the free monitor covers it. The overage only bites once you're past one.
When is it overkill, and what's a lighter alternative?
The mismatch shows up for the solo dev or small team watching more than one service who doesn't already live in Sentry for error tracking. Standing up a Sentry project to get an HTTP poller is a lot of platform for the job, and once you're past the single included monitor, every additional check is a recurring line item, not a flat rate.
There's also the alert-destination gap: Sentry's integrations cover Slack, Microsoft Teams, PagerDuty, Opsgenie, Discord, Twilio SMS, and a few incident tools, but not Telegram. If a chat app on your phone is actually where you want to see "your API just went down," you're bridging it yourself with a webhook relay, or going elsewhere.
CanaryHub covers the same outside-in HTTP check without the platform or the per-monitor meter. You point it at a URL in the dashboard the same way, no code required, and it's unlimited monitors on the Pro plan rather than billed one at a time. Checks run as fast as every 60 seconds on Pro (5 minutes on the free tier), and alerts go to Telegram by default, with Email, Slack, and Discord also live. There's no issue stream to open; the alert lands in the chat you already check.
It also covers the other half of "is this thing working," the part a URL poller can't see: a background job or cron task that silently stops running. That's a one-line addition at the end of the script, after the real work succeeds:
curl -fsS https://ingest.canaryhub.ai/ping/<your-token>
If the ping goes quiet past the job's expected interval, the monitor treats the silence itself as the failure signal, the same dead man's switch pattern covered in how to monitor a cron job.
Here's the honest split:
Sentry Uptime Monitoring
+ Outage issues sit next to the errors and traces from the same service
+ One alert pipeline if you already route Sentry issues to on-call
+ Flexible checks: any HTTP method, custom headers, request body, assertions
- One monitor included per plan regardless of tier; $1/mo per monitor beyond that
- No native Telegram integration
- Requires a Sentry project and account to use at all
CanaryHub
+ Unlimited monitors on Pro, flat $8.99/mo instead of metered per monitor
+ Telegram-first alerting (plus Email, Slack, Discord)
+ Also does cron/heartbeat dead man's switch monitoring in the same tool
- No error tracking, tracing, or session replay
- No issue-level correlation with application exceptions
If a failed check needs to land next to the stack trace that caused it, Sentry's integration is worth the per-monitor cost. If you just want to know the URL is down and get a text, a dedicated tool costs less once you're past one thing to watch, and lands somewhere you'll actually see it.