Sentry sells uptime monitoring. So who monitors Sentry?
Sentry's official status hostname is status.sentry.io. It lists incidents affecting the API and error ingestion. That page is not Sentry's origin: DNS shows it pointing at an Atlassian Statuspage customer hostname.
Even companies that sell monitoring use an independent system to expose their own availability. A status surface is only useful if it can still report an outage when the product it describes is unavailable.
We keep a separate record at devhelm.io/status/sentry, from probes that do not share Sentry's infrastructure.
The question, then, is not "why doesn't Sentry monitor itself?" It is why any uptime monitoring system should depend entirely on the infrastructure it is supposed to watch.
Why independent uptime monitoring exists
When the watcher shares fate with the thing being watched, one outage can take both down. The app stops responding, the status URL fails with it, and alerting never fires because it lived on the same path. Customers refresh a blank tab and search "is it down."
Independent uptime monitoring is the same idea applied to your product: scheduled probes from networks you do not control, against the URL your users actually hit, rather than a dashboard in the VPC or a health endpoint only your load balancer can see.
Other uptime tools do a version of the same pattern: branded status.* hostnames on infrastructure they do not operate.
Get posts like this in your inbox
Engineering insights on monitoring, incidents, and uptime. Bi-weekly, 2-minute read.
Status pages do not probe your origin
A hosted status page does not hit your production URL on a schedule. Graphs and automatic component flips need an external monitor or a custom integration. The page is a communications surface. Someone else has to do the checking, or an engineer types the incident by hand.
That is why hosting the board elsewhere is a resilience choice, not a gap. If the product is degraded, a status page on the same stack is often the first thing customers cannot load. The status page guide covers how to structure components and incidents. The constraint is simple: the page that says you are down should not go down with you.
An independent check can feed a status page. The page cannot stand in for the check.
Most uptime tools run their own probes and only borrow the status-page layer. A few put the public check UI on another vendor. They still keep the public notice board off the app.
Two separations
Mixing "who hosts the status page" with "who runs the probe" produces the wrong purchase.
First, separate your application from the thing that watches it. Internal health endpoints, APM, and error trackers (Sentry included) are necessary, and they share your runtime. A load balancer can show healthy pods while the public hostname returns 502. External checks exist for that class of failure. For SSL expiry, DNS cutovers, and regional probes, use the uptime guide.
Second, if you need to read "the vendor is down" during a vendor outage, their public status has to sit outside that vendor's product. Sentry's official status.sentry.io hostname is the public example.
For your product, the vendor-status hostname is optional. The external probe is required. If your only signal is a dashboard inside the same cluster as the app, you will learn about edge and DNS failures from a customer email.
The question to ask
Most vendors can monitor themselves, and do.
Ask whether the observer you are buying sits outside your infrastructure: a different network, DNS, cloud account, and deploy. Ask, separately, whether their public status page would still load if their app did not.
Keep the traces and the error tracker. Add an external probe on the user path. Keep the status page somewhere that is not the origin it describes.
See how we keep probes independent of the control plane at devhelm.io/reliability.
Get posts like this in your inbox
Engineering insights on monitoring, incidents, and uptime. Bi-weekly, 2-minute read.