GCP-Störung

 (status.cloud.google.com)
2 Punkte von GN⁺ 2025-06-13 | 1 Kommentare | Auf WhatsApp teilen
  • Das Google Cloud Service Health-Dashboard zeigt den Status von Google-Cloud-Diensten nach Produkt und Standort an; der aktuelle Bildschirm weist den Status keine schwerwiegenden großflächigen Störungen aus
  • Die Auswirkungen auf einzelne Projekte lassen sich möglicherweise nicht allein über das Gesamtdashboard erfassen; daher sollte in Personalized Service Health nach benutzerdefinierten Benachrichtigungen, API-Daten und Logs geschaut werden
  • Der Statusbereich ist in Americas, Europe, Asia Pacific, Middle East, Africa, Multi-regions und Non-regional unterteilt; der Status je Produkt lässt sich entlang der Standortachse einsehen
  • Multi-regions sind redundante und verteilte Standorte über mehrere Regionen hinweg, Non-regional zeigt den Status von global bereitgestellten Diensten an, die keiner bestimmten Region zugeordnet sind
  • Es werden Vorfallverlauf, RSS, JSON History und JSON Product Catalog bereitgestellt; die angezeigte Zeit basiert auf US/Pacific, die letzte Aktualisierung erfolgte am 3. Juli 2026 um 12:35 PDT

Aktueller Google-Cloud-Status

  • Google Cloud Service Health stellt Statusinformationen zu Google-Cloud-Diensten bereit
  • Der aktuelle Status oben im Dashboard wird als No broad severe incidents angezeigt
  • Bei Ereignissen, die sich auf Projekte auswirken können, wird darauf hingewiesen, diese in der kontobezogenen Ansicht zu prüfen
  • Die letzte Aktualisierung erfolgte am 3. Juli 2026 um 12:35 PDT

Störungen pro Projekt prüfen

  • Personalized Service Health zeigt Vorfälle, die Google-Cloud-Projekte betreffen, detaillierter an
    • Benutzerdefinierte Benachrichtigungen
    • API-Daten
    • Logs
  • Die Prüfung des kontobezogenen Status erfolgt durch Wechsel zum Google-Cloud-Konto

Statusstruktur nach Produkt und Standort

  • Im Dashboard lässt sich der Status je Produkt entlang der Standortachse aufgeteilt prüfen
    • Americas
    • Europe
    • Asia Pacific
    • Middle East
    • Africa
    • Multi-regions
    • Non-regional
  • Multi-regions sind von Google verwaltete Service-Standorte, die so ausgelegt sind, dass sie innerhalb eines großen geografischen Gebiets redundant und verteilt über mehrere Regionen hinweg betrieben werden
  • Non-regional zeigt den Status von Diensten an, die nicht an einen bestimmten Standort gebunden, sondern global bereitgestellt sind
    • Aktualisierungen in diesem Bereich bedeuten ein Problem bei dem jeweiligen Dienst
    • Sie bedeuten nicht zwingend eine plattformweite Störung, die alle Regionen betrifft

Statuskennzeichnung und betroffene Dienste

  • Die Statuslegende enthält Available und Multiple regions affected
  • Die Statustabelle umfasst verschiedene Produkte von Google Cloud
    • Google Compute Engine
    • Google Kubernetes Engine
    • Google Cloud Storage
    • Google BigQuery
    • Cloud Run
    • Cloud SQL
    • Vertex AI-bezogene APIs und Dienste
    • IAM, VPC, Cloud Logging, Cloud Monitoring usw.
  • Jedes Produkt ist so aufgebaut, dass der Status nach Standort gemeinsam eingesehen werden kann

Vorfallverlauf und Datenzugriff

  • Unter View incident history lässt sich der Vorfallverlauf einsehen
  • Statusdaten werden in mehreren Formaten bereitgestellt
  • Für Vorfälle im Zusammenhang mit Google Security Products wird auf eine separate Statusseite verwiesen
  • Für Vorfälle im Zusammenhang mit Looker original wird ebenfalls auf eine separate Statusseite verwiesen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-13
Hacker-News-Meinungen

  • Googles zentraler Dienst Chemist scheint ausgefallen zu sein
    „Chemist checks the project status, activation status, abuse status, billing status, service status, location restrictions, VPC Service Controls, SuperQuota, and other policies.“
    Das erklärt also Fehler wie „visibility check (of the API) failed“ und „cannot load policy“ sowie die weitreichenden Auswirkungen auf Dienste
    Siehe: https://cloud.google.com/service-infrastructure/docs/service...
    Außerdem erklärte Google, „(Google Cloud) is down due to Identity and Access Management Service Issue“

    • Nicht nur GCP, sondern auch mehrere Internetdienste waren ausgefallen
      Möglicherweise ist dieser Chemist-Dienst besonders anfällig für externe Abhängigkeiten, sodass sich der Ausfall bis auf interne GCP-Netzwerkdienste ausgebreitet hat
    • Wir nutzen Expo-Relay für Benachrichtigungen; in diesem Google-Kontext frage ich mich, ob auch FCM mitbetroffen sein könnte

  • Bei Claude Sonnet 4 (Cursor) und Gemini Pro treten viele Fehler auf
    Oh nein, jetzt muss ich wieder mein Gehirn benutzen und 100 % des Codes selbst schreiben, wie ein Steinzeitmensch im Dezember 2024

    • Auch in AI Studio tritt dasselbe Problem auf: Failed to generate content: user has exceeded quota. Please try again later.
    • Ich war gerade dabei, Datei-Uploads in Cloud Storage zu testen; scheint ein guter Zeitpunkt für einen Spaziergang zu sein
    • Auch im Auto-Agent-Modus von Cursor treten Fehler auf
    • Entwickler vor dem 12. Juni 2025: „AI? Pah, ist doch nur ein Haufen Halluzinationen. Die wird mich niemals ersetzen!“
      Entwickler während des GCP-Ausfalls am 12. Juni 2025: „Wie bitte, keine AI?! Haltet ihr mich für einen Sklaven?!“
    • openrouter.ai ist ebenfalls nicht erreichbar

  • Auch Cloudflare ist ausgefallen. Laut https://www.cloudflarestatus.com:
    „Update - We are seeing a number of services suffer intermittent failures. We are continuing to investigate this and we will update this list as we assess the impact on a per-service level.“
    Betroffene Dienste sind Access, WARP, SQLite-basierte Durable Objects, Workers KV, Realtime, Workers AI, Stream sowie Teile des Cloudflare-Dashboards
    12. Juni 2025, 18:48 UTC
    Ergänzung: https://news.ycombinator.com/item?id=44261064

    • Wenn Cloudflare GCP als Kernabhängigkeit nutzt, wirkt das nach einem ziemlich heftigen WTF

  • Um 18:43 UTC schien fast alles ausgefallen zu sein: https://downdetector.com/

    • Stimmt. Die Charts dieses Dienstes waren vermutlich Ergebnisse, die intern bei GCP erkannt wurden
      Während eines Telefonats mit einem Google-Mitarbeiter sagte jemand: „AWS ist auch down“, und bevor ich selbst die AWS-Verfügbarkeit überprüft hatte, sagte ich voreilig: „Es könnte auch ein BGP-Angriff sein.“ Peinlich
    • Interessant, weil ich nicht erwartet hätte, dass ein Google-Ausfall auch AWS oder Microsoft 365 beeinträchtigen würde
    • Vielleicht läuft die Erkennungslogik in Google Cloud /s
    • Bei solchen Vorfällen verbreitet Downdetector zu 100 % falsche Informationen

  • Die Statusseite ist grün, aber es gehen Störungsmeldungen ein: https://downdetector.com/status/google-cloud/

    • Wenn das so ist, weiß ich nicht, wozu es überhaupt Statusseiten gibt
      Es gab auch Berichte, dass eine Organisation mit über 100.000 Nutzern Google Meet nicht verwenden konnte. Wenn Unternehmen ihre Statusseiten nicht aktualisieren, wären sie besser gar nicht erst da
      https://www.google.com/appsstatus/dashboard/
      https://status.cloud.google.com/index.html
      Nachtrag: Keine Minute nachdem ich das gepostet hatte, wurde die GCP-Statusseite aktualisiert; als betroffene Dienste werden Cloud Data Fusion, Cloud Memorystore, Cloud Shell, Cloud Workstations, Google Cloud Bigtable, Google Cloud Console, Google Cloud Dataproc, Google Cloud Storage, Identity and Access Management, Identity Platform, Memorystore for Memcached, Memorystore for Redis, Memorystore for Redis Cluster und Vertex AI Search angezeigt
    • Der Incident-Link ist hier: https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1S...
    • Ich verstehe nicht, warum Unternehmen Störungen nicht offen eingestehen können. Dann irren wir nicht eine Stunde lang herum und denken, es sei ein internes Problem
      Wirklich ein Zustand, der in Gottes Hand liegt
      $ prod
      Fetching cluster endpoint and auth data.
      ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=503, message=Visibility check was unavailable. Please retry the request and contact support if the problem persists
    • In einem Remote-Unternehmen mit mehreren Hundert Leuten schlagen Verbindungen zu Google Meetings zu über 90 % fehl. Wenn man einem Meeting beitritt, bekommt man einfach einen 504
    • Jetzt wurde es aktualisiert, und Auswirkungen auf Console, Dataproc, GCS, IAM und Identity Platform werden angezeigt: https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1S...

  • Seltsam, dass wegen dieser Störung sogar RCS Messaging ausgefallen ist. Das zeigt, wie wacklig die Technik oder das Infrastrukturdesign ist

    • Ist RCS nicht im Grunde einfach Instant Messaging? Ich weiß nicht, warum es überraschend sein soll, dass das ausfällt
    • Deshalb habe ich heute also die Hundefotos meiner Eltern nicht bekommen
    • Meine Güte, deshalb ist also vorhin mein RCS-Chat fehlgeschlagen?!

  • Firebase Authentication ist ausgefallen und betrifft viele Apps. In Discord- und Slack-Gruppen kommen ebenfalls massenhaft entsprechende Bestätigungen rein
    Dass auf der Statusseite fast 30 Minuten lang gar nichts steht, ist schon etwas enttäuschend: https://status.firebase.google.com/

    • Wurde gerade aktualisiert. Vermutlich waren sie selbst von ihrer Störung betroffen

  • Die Cloudflare-Störung wurde ebenfalls gerade aktualisiert
    „Cloudflare’s critical Workers KV service went offline due to an outage of a 3rd party service that is a key dependency. As a result, certain Cloudflare products that rely on KV service to store and disseminate information“

    • Ist dieser Drittanbieterdienst GCP?

  • Ich frage mich, ob jemand ein gutes Dashboard kennt, mit dem man solche BGP-Routing-Anomalien, wie sie hier zu sehen scheinen, prüfen kann
    Ich durchforste gerade https://radar.cloudflare.com/routing, aber es zeigt nicht, welche Routen tatsächlich geleakt wurden
    Empfehlungen für gute Tools wären willkommen

  • Zum Glück wird HN ohne diesen ganzen aufgeblähten Kram auf einem einzigen Bare-Metal-Server gehostet

    • Ich erinnere mich aber auch an ziemlich viele Fälle, in denen HN down war