Sentry statusLiveFetched seconds agoSource: status.sentry.io
Is Sentry down?
Live status check · All systems operational
Live status pulled from status.sentry.io, cached and revalidated every 60 seconds. Below: the components that can break, what to do during an incident, and how to keep your scheduled jobs running independently.
About Sentry status
Sentry is the leading error-tracking, performance-monitoring, and session-replay platform for application developers. Incidents usually scope to one component (event ingestion, the Issues dashboard, or the alerts pipeline) rather than the whole product, so the status page is worth reading carefully before you assume Sentry is fully down.
Components and surfaces that can break
- Surface 01
Event ingestion (api.sentry.io and the *.ingest.sentry.io endpoints used by the SDKs).
- Surface 02
Dashboard, Issues, and Discover queries in sentry.io.
- Surface 03
Alerts and integrations (Slack, PagerDuty, email, webhooks).
Recent Sentry incidents
Sentry maintains a public incident history. Read the latest entries to see whether you're hitting a known issue, and look at the post-mortems for context on how long similar incidents typically take to clear.
What to do if Sentry is actually down
Events are buffered client-side during ingestion outages
Sentry's SDKs queue events locally when api.sentry.io or the ingest endpoints are unreachable, then flush them once ingestion recovers. Events typically arrive late rather than being lost, so resist the urge to add a second error sink just to cover a short ingestion blip.
A broken Issues UI does not always mean silent alerts
The sentry.io dashboard, Issues, and the alerts pipeline are tracked as separate components on status.sentry.io. If only the UI is degraded, alert routing to Slack, PagerDuty, and email often keeps firing. Check the component breakdown before assuming you are flying blind.
If Alerts is the affected component, pair Sentry with a second watcher
When the Sentry Alerts pipeline itself is degraded, critical issues can go unnoticed because no notification ever leaves Sentry. For production-critical paths, run an independent watcher (a Crontap probe against a health endpoint, or a separate uptime check) so an outage inside Sentry does not also blind your on-call.
Keep firing through the incident
Schedule your own Sentry health check with Crontap
Daily new-issues digest to #engineering, weekly stale-issue auto-close, monthly release-health rollup. Crontap fires the endpoint that hits Sentry's Issues API on the cadence you set and processes the result, with retries on transient 5xx and an email if the job fails.
External HTTP cron hits your endpoint on the cadence you pick, stores every response, and emails you the moment a run fails. Pro schedules down to 1 minute; $3.25/mo annual flat for unlimited jobs.
Go deeper
Sentry status: FAQ
- Where can I see the official Sentry status?
- status.sentry.io publishes component-level status for event ingestion, the dashboard, alerts, and integrations. The history page at status.sentry.io/history lists past incidents with timestamps and post-mortems, and an Atom feed is available at status.sentry.io/history.atom for piping into your own tooling.
- Can I verify Sentry is receiving my events on a schedule?
- Yes. Schedule a Crontap probe against a small endpoint on your app that captures a known test event (for example Sentry.captureMessage('crontap-heartbeat')) and then queries Sentry's Issues API for that fingerprint within the last few minutes. If the event is not found, Crontap alerts you, which catches both ingestion incidents and silently broken DSN configuration.
- How do I get alerted if Sentry Alerts itself goes down?
- Do not rely solely on Sentry to tell you Sentry is broken. Run an independent Crontap probe every 1-5 minutes against a /api/health endpoint that exercises the same code path your production alerts cover. If something underlying breaks but no Sentry alert ever fires, Crontap will still email you, and the absence of a matching Sentry notification tells you the alerts pipeline is the real problem.