Where does this status come from?

From Sentry's own status page API at https://status.sentry.io. UpButler reads it once for everyone (not once per visitor) every 120 seconds with conditional requests, and shows it unchanged: incident titles and component names are Sentry's words.

How can my agent or app check Sentry status?

Fetch https://upbutler.com/status/sentry/status.agent.json: a small JSON document with a verdict (proceed, retry, fallback or pause) and retryAfterSec. No key is needed. The same answer is an MCP tool, upstream_status {"service":"sentry"}, on https://upbutler.com/mcp/public.

How do I know whether an outage is mine or Sentry's?

Add "sentry" to the dependencies of your UpButler workspace. When one of your monitors fails while Sentry has an incident that began around the same time, your incident is tagged "likely upstream" with their incident linked, and your on-call agent is told not to change code.

Is Sentry down?

Right now

No. Sentry is operational.

No incidents reported.

Read from status.sentry.io 2 min ago · every 120s

For agents

proceed

Proceed.

GET upbutler.com/status/sentry/status.agent.json

MCP: upstream_status {"service":"sentry"}

Error and performance monitoring. During an ingestion incident errors are delayed, so a quiet Sentry is not proof of health.

What Sentry reports

Operational

Taken as is from Sentry's own status page API. Incident titles and component names below are theirs.

Open status.sentry.io

UpButler's independent probe

There is no keyless endpoint of Sentry that says anything useful, so UpButler does not probe it. To check your own Sentry account, add a monitor with your key: it is yours alone and catches what a shared probe cannot.

Open at Sentry

US: Span ingestion temporarily delayed and alerting offline for database maintenancescheduled maintenance
Starts 2026-10-14 03:00 UTC · US Spans Alerting, US Span Ingestion, US Cron Monitoring, US Uptime Monitoring
We will be performing a database migration in the US region that will pause span ingestion and disable span alerting for up to 2 hours. The Sentry UI and API should be available for the duration, but there will be a period of catch-up where ingestion will be behind and alerts will not fire (until ingestion has reached fresh data).

Text written by Sentry, shown unchanged.

Sentry components

41 operational

DashboardOperational
APIOperational
Integration PipelineOperational
SeerOperational

Notification Delivery

SlackOperational
EmailOperational
PagerDutyOperational
Microsoft TeamsOperational

Authentication Services

Password-BasedOperational
GoogleOperational
GitHubOperational
Azure DevOpsOperational
SAML-Based Single Sign-OnOperational

US Ingestion

US Error IngestionOperational
US Transaction IngestionOperational
US Attachment IngestionOperational
US Profile IngestionOperational
US Replay IngestionOperational
US Span IngestionOperational
US Cron MonitoringOperational
Custom Metrics (beta)Operational
US Size Analysis IngestionOperational
US Snapshot IngestionOperational

EU Ingestion

EU Error IngestionOperational
EU Transaction IngestionOperational
EU Attachment IngestionOperational
EU Profile IngestionOperational
EU Replay IngestionOperational
EU Span IngestionOperational
EU Cron MonitoringOperational
EU Size Analysis IngestionOperational
EU Snapshot IngestionOperational

Alerting

US Errors AlertingOperational
EU Errors AlertingOperational
US Transactions AlertingOperational
US Spans AlertingOperational
EU Transactions AlertingOperational
EU Spans AlertingOperational
US Uptime MonitoringOperational
EU Uptime MonitoringOperational

Third-Party Integrations

StripeOperational

Sentry incidents, last 90 days

1 finished incident seen since UpButler started tracking on 2026-10-10, 1 of them rated major or critical by Sentry.

Started (UTC)	Incident	Impact	Lasted
2026-10-06 18:57	Sentry dashboard down	critical	42 min

Tell your outage from Sentry's

Declare that your project depends on Sentry. When one of your monitors fails while Sentry has an incident that began around the same time, UpButler tags your incident "likely upstream" with their incident linked, says so in the alert and the AI report, and tells your on-call agent not to change code.

npx upbutler init finds the dependency from your env var names and packages. The catalog, dependencies and upstream-aware incidents are on every plan, including Free.

Start free How it works

upbutler.yaml

# upbutler.yaml
dependencies:
  - sentry

Ask before you retry

curl -s https://upbutler.com/status/sentry/status.agent.json

status.agent.json (live)

{
  "schema": "upbutler.upstream-status/v1",
  "service": "sentry",
  "verdict": "proceed",
  "status": "operational",
  "reason": "No incidents reported",
  "retryAfterSec": null,
  "incident": null,
  "probe": null
}

Questions

Is Sentry down right now?: No. As of 2026-10-10 05:10 UTC, Sentry is operational. This page reads the status again every 2 minutes.
Where does this status come from?: From Sentry's own status page API at https://status.sentry.io. UpButler reads it once for everyone (not once per visitor) every 120 seconds with conditional requests, and shows it unchanged: incident titles and component names are Sentry's words.
How can my agent or app check Sentry status?: Fetch https://upbutler.com/status/sentry/status.agent.json: a small JSON document with a verdict (proceed, retry, fallback or pause) and retryAfterSec. No key is needed. The same answer is an MCP tool, upstream_status {"service":"sentry"}, on https://upbutler.com/mcp/public.
How do I know whether an outage is mine or Sentry's?: Add "sentry" to the dependencies of your UpButler workspace. When one of your monitors fails while Sentry has an incident that began around the same time, your incident is tagged "likely upstream" with their incident linked, and your on-call agent is told not to change code.

More in observability and analytics

UpButler is not affiliated with Sentry. Status and incident text belong to Sentry and are read from their public status source; the probe result is UpButler's own measurement.