Degraded Database Attach Times in eu-central-1
This incident is resolved. The fix was applied at approximately 11:50 UTC and database and share attach times in eu-central-1 have returned to normal levels. The degradation came from excessive load on an internal metadata service in the region, which slowed the step that opens a...
The latest update from MotherDuck.
State
Resolved
Started
68 d ago
2026-08-26 08:02 UTC
Lasted
4 h 51 min
until 2026-08-26 12:53 UTC
Worst impact
Partial outage
Timeline
7 updatesInvestigating
4 h 51 min 100%
Updates
Times in UTCAs posted by MotherDuck
This incident is resolved. The fix was applied at approximately 11:50 UTC and database and share attach times in eu-central-1 have returned to normal levels. The degradation came from excessive load on an internal metadata service in the region, which slowed the step that opens a...
We have applied a fix and database and share attach times in eu-central-1 have returned to normal levels as of approximately 11:50 UTC. New connections should now establish normally, and any request that failed during the incident can be retried. We are monitoring closely before...
Our team are continuing to work on implementing a work around and to reduce the load on our internal database, which causes the performance issues with attaches (both for MD databases and shares). We will post update here once the issue is resolved!
Our team has identified the issue and are attempting potential fixes. Thank you for your patience as we continue to investigate and work towards a resolution!
We are continuing to investigate the degraded attach times in the eu-central-1 region. Our team has identified that some background jobs are putting unreasonable load on the system and these jobs have been paused. We are continuing to explore fixes. Apologies for the impact!
We are continuing to investigate the degraded attach times in the eu-central-1 region. Our team has identified that some background jobs are putting unreasonable load on the system. These jobs have been paused and we are exploring potential fixes. Apologies for the impact!
We are investigating degraded database and share attach times in eu-central-1 region. Our team is investigating the issue with high priority!
Affected components
1MotherDuck in the last 90 days
Full historyIncidents in 90 days
3
Days with an incident
3
Median duration
58 min
This incident
5.0× the median
Other MotherDuck incidents
All incidentsFollow MotherDuck
Your coding agent knows when MotherDuck is down, and tells you when a failure is theirs, not yours. You can also get MotherDuck 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.cc/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 "motherduck" and tell me if MotherDuck 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.cc/feed.xml?providers=motherduck/feed subscribe https://outages.cc/feed.xml?providers=motherduckFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane