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
The latest update from Better Stack.
State
Resolved
Started
59 d ago
2026-09-04 13:50 UTC
Lasted
2 days
until 2026-09-06 19:13 UTC
Worst impact
Degraded
Timeline
4 updatesDegraded
2 days 100%
Updates
Times in UTCAs posted by Better Stack
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
Live data is coming in. Historical data is backfilling at a steady rate, we expect several more hours until all data is processed. Thank you for your patience. Please reach out to [hello@betterstack.com](mailto:hello@betterstack.com) with any questions.
Processing of new data in the Europe region is starting to recover. Backfilling delayed data will take longer, so older timestamps may still be missing. No data has been lost.
We're seeing delayed data processing for some sources located in the Europe region again. The team is looking into resolving as soon as possible. There has been no data loss, all incoming data is ingested and will become visible as the system catches up. If you have any questions, please reach out to [hello@betterstack.com](mailto:hello@betterstack.com). Thank you for your patience!
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
1.9× 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
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.
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