[Generative-Apis] [fr-par] - mistral-small-3.2-24b-instruct-2506 outage
[11/12 - 9:45 UTC+1] The incident has been mitigated, service is back to normal
The latest update from Scaleway.
State
Resolved
Started
Lasted
1 min
Worst impact
Degraded
Timeline
2 updatesIdentified
1 min 86%
Resolved
1 min 14%
Updates
Times in UTCAs posted by Scaleway
[11/12 - 9:45 UTC+1] The incident has been mitigated, service is back to normal
[11/11 - 15:15 UTC+1] One mistral-small-3.2-24b-instruct-2506 backend started to become unresponsive As a consequences, the rate of http 504 increased during the perdio
Affected components
8Scaleway in the last 90 days
Full historyIncidents in 90 days
73
Days with an incident
38
Median duration
13 h 24 min
This incident
100% shorter than the median
Other Scaleway incidents
All incidentsScaleway·[Containers/Functions] - [fr-par] - private endpoints might not be available
Scaleway reports that private endpoints for Serverless Containers and Serverless Functions in the fr-par region may not be available. Only some containers attached to a private network are affected. Scaleway is investigating.
Scaleway·[ElasticMetal] - [world] - The private_network option is not working as expected in the Terraform provider.
The privatenetwork option does not work as expected in the Scaleway Terraform provider for Elastic Metal in all regions. Scaleway reports that it is investigating the problem.
Scaleway·[WEBHOSTING] [fr-par] pf-1010.whm.fr-par.scw.cloud
Scaleway reports that the webhosting service pf-1010.whm.fr-par.scw.cloud in the fr-par region did not work. Scaleway identified a failed MySQL upgrade and performed a rollback with a backup. The incident is resolved and lasted about 47 minutes.
Scaleway·[DC3] Interlink Router device at dc3 lost the connexion with the Interlink Route Reflector
The interlink router at Scaleway DC3 lost its connection to the Interlink Route Reflector. Scaleway reported that some customers on this router may have had about 4 minutes of disruption to production traffic. Scaleway states that the incident is resolved, and it lasted about 45 minutes.
Scaleway·[DOMAIN - DNS] - ns0.online.net and ns0.dom.scw.cloud down
Scaleway reports that DNS resolution does not work on the nameservers ns0.online.net and ns0.dom.scw.cloud over IPv4. The Domains components and the Dedibox and Elements Domains products are affected. Scaleway resolved the incident after 14 minutes.
Follow Scaleway
Your coding agent knows when Scaleway is down, and tells you when a failure is theirs, not yours. You can also get Scaleway 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 "scaleway" and tell me if Scaleway 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=scaleway/feed subscribe https://outages.live/feed.xml?providers=scalewayFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane