Delayed data processing in the Europe region
Data processing in the Europe region has returned to normal following yesterday's migration. No data was lost. Some remaining historical data is catching up and will be filled shortly. We apologize for the trouble and thank you for your patience! Please reach out to hello@betterstack.com with any questions. We'll be happy to help.
The latest update from Better Stack.
State
Resolved
Started
60 d ago
2026-09-03 02:15 UTC
Lasted
28 h 4 min
until 2026-09-04 06:19 UTC
Worst impact
Degraded
Timeline
2 updatesDegraded
28 h 4 min 100%
Updates
Times in UTCAs posted by Better Stack
Data processing in the Europe region has returned to normal following yesterday's migration. No data was lost. Some remaining historical data is catching up and will be filled shortly. We apologize for the trouble and thank you for your patience! Please reach out to hello@betterstack.com with any questions. We'll be happy to help.
We're seeing delayed data processing for some sources located in the Europe region following the scheduled migration. There's no data loss, all incoming data is ingested and will become visible as the system catches up. If you have any questions, feel free to reach out at [hello@betterstack.com](mailto:hello@betterstack.com).
Affected components
1Better Stack in the last 90 days
Full historyIncidents in 90 days
3
Days with an incident
5
Median duration
28 h 4 min
This incident
About the median
Other Better Stack incidents
All incidentsBetter Stack·Incorrectly sent out downtime notifications to single-region monitors due to intermittent Internet backbone issue
The issue has been resolved. We apologize for the trouble Need help? Please let us know at hello@betterstack.com
Better Stack·Delayed data processing in the Europe region
This incident is now resolved. All sources in the Europe region are processing in real time and the delayed backlog has been processed in full. What happened: On September 3, we consolidated several EU Telemetry clusters onto new, higher-capacity infrastructure. The cutover multiplied concurrent write streams on the cluster, and the volume of concurrent inserts saturated per-host write throughput on I/O contention. Ingestion fell behind, and affected sources saw delays in Live tail, dashboards, alerts, and queries. Our initial fixes, tuning the write path and adding capacity, restored real-time ingestion within a day, but draining the backlog alongside live traffic re-created the contention. We then rebuilt the recovery pipeline and held live data with strict priority while separately replaying the backlog at a controlled rate. Replaying several days of data was the slowest part of the recovery by design, as we rate-limited the replay so that real-time ingestion wasn't put at risk. We
Follow Better Stack
Your coding agent knows when Better Stack is down, and tells you when a failure is theirs, not yours. You can also get Better Stack 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 "betterstack" and tell me if Better Stack 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=betterstack/feed subscribe https://outages.live/feed.xml?providers=betterstackFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane