EU region replay ingestion latency
Sentry reports replay event ingestion latency in the EU region. The affected components are EU Replay Ingestion and EU Ingestion - EU Replay Ingestion. Sentry resolved the issue, and the outage lasted about 48 minutes.
State
Resolved
Started
Lasted
48 min
Worst impact
Degraded
Timeline
2 updatesIdentified
48 min 100%
Updates
Times in UTCAs posted by Sentry
We have resolved the issue causing ingestion latency for replay events in our EU region.
We have identified an issue causing ingestion latency for replay events in our EU region and are working on a fix.
Affected components
2Sentry in the last 90 days
Full historyIncidents in 90 days
23
Days with an incident
17
Median duration
1 h 45 min
This incident
54% shorter than the median
Other Sentry incidents
All incidentsSentry·Ingestion delays across all data
Sentry reported ingestion delays for all US data. The affected components were US Error, Transaction, Attachment, Profile, Replay, Span, Cron Monitoring, and Custom Metrics ingestion. Sentry resolved the incident after 70 minutes, and latency returned to normal.
Sentry·Delays in spans and transactions processing
Sentry span and transaction ingestion had delays in the US. The affected components were US Transaction Ingestion and US Span Ingestion. Sentry resolved the issue. The incident lasted about 105 minutes. No data was lost.
Sentry·Sentry.io dashboard and API is down
Sentry reported that the Dashboard and API did not work for US and EU customers. Sentry later reported that the issue was mitigated and the components were operational. Sentry reported that the issue is resolved. It lasted about 93 minutes.
Sentry·Sentry dashboard is down
Sentry dashboard and API had a major outage. The problem affected both US and EU customers. Sentry reported the incident as resolved and it lasted 4 hours and 21 minutes.
Sentry·Increased latency processing integration webhooks
We are working on mitigating an incident that affects external integrations such as GitHub, Slack, and Autofix PRs. No data is being lost.
Follow Sentry
Your coding agent knows when Sentry is down, and tells you when a failure is theirs, not yours. You can also get Sentry incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.live/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "sentry" and tell me if Sentry has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.live/feed.xml?providers=sentry/feed subscribe https://outages.live/feed.xml?providers=sentryFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane