Loading status…
Loading status…
Scaleway status · Cloud & Infrastructure · checked (0s ago)
Partly — Scaleway is up but running slower than usual (Partially Degraded Service).
According to Scaleway's official status page, Scaleway was reporting “Partially Degraded Service” when isuptime last checked at . Over the last 30 days, Scaleway's feed reported no outage in 100.00% of our checks.
isuptime cannot fix Scaleway, and neither can you. These are the things that are actually worth doing until it comes back.
Everything above is read from Scaleway's own status feed. This is what other visitors are saying in the last 24 hours — useful when the feed is green and you are still stuck, and never used to change the status above.
Nobody has reported Scaleway in the last 24 hours. Yours would be the first.
Reports are anonymous counts and are kept for 24 hours, then deleted. No account, no message, nothing stored about who reported. One report per service per hour, changeable until the hour is out.
Scaleway is a European cloud provider offering instances, Kubernetes, object storage, managed databases and serverless, run from its own data centres in France, the Netherlands and Poland. It is used heavily by teams with a data residency requirement that rules out the American hyperscalers.
Scaleway's status page reports per product and per availability zone, and it reports actively — planned maintenance on a single zone appears alongside real incidents, so the aggregate indicator sits amber more often than the platform is genuinely impaired. Read which zone is affected before concluding anything: PAR, AMS and WAW fail independently.
isuptime reads this feed on a schedule and reports what it says — how that works, in detail.
One bar per day. Each shows the share of that day's checks where Scaleway's own status feed reported no outage — degraded counts as no-outage. Days with no bar are days isuptime recorded no checks, not days Scaleway was down.
13 other services isuptime tracks were also reporting a problem as of the same check, 0s ago. They are checked on one schedule, so the timing is comparable — but overlapping in time does not mean they share a cause.
Each point is one check of Scaleway's status endpoint.
Scaleway has published 50 incidents in the last 12 months, the 20 most recent shown here. Only what Scaleway posted itself — not every problem users hit.
resolved · Sep 18, 02:29 PM (1d ago)
monitoring · Sep 18, 01:45 PM (1d ago)
resolved · Sep 17, 07:59 AM (2d ago)
resolved · Sep 16, 01:52 PM (3d ago)
resolved · Sep 16, 06:22 AM (3d ago)
resolved · Sep 15, 05:03 PM (4d ago)
resolved · Sep 15, 02:02 PM (4d ago)
resolved · Sep 15, 01:59 PM (4d ago)
resolved · Sep 15, 12:55 PM (4d ago)
resolved · Sep 14, 03:34 PM (5d ago)
identified · Sep 14, 01:11 PM (5d ago)
investigating · Sep 14, 10:49 AM (5d ago)
resolved · Sep 14, 09:09 AM (5d ago)
resolved · Sep 11, 07:43 AM (8d ago)
investigating · Sep 10, 10:06 AM (9d ago)
resolved · Sep 9, 08:35 AM (10d ago)
resolved · Sep 8, 01:49 PM (11d ago)
resolved · Sep 8, 10:42 AM (11d ago)
resolved · Sep 8, 09:44 AM (11d ago)
resolved · Sep 8, 07:31 AM (11d ago)
Confirm the zone your resources live in rather than the one in the incident. Quota limits on instance types are per-project and produce allocation failures that look like capacity outages. A specific instance type being unavailable in one zone is common and normal, and Scaleway does not post it as an incident.