Störungsverlauf von Elastic Cloud

1. 23. Oktober 2026 um 04:04 UTCinvestigating

   Wir untersuchen derzeit ein Problem, das den Zugang zum Portal Elastic Support verhindert. Zu diesem Zeitpunkt können Kunden Probleme bei der Authentifizierung gegenüber dem Support-Portal haben.

2. 23. Oktober 2026 um 04:59 UTCidentified

   Wir haben ein Problem festgestellt, das den Zugriff auf das Elastic Support-Portal durch einen Upstream-Anbieter verhindert. Der Anbieter hat einen Fix bestätigt, der den Zugang für einige seiner betroffenen Umgebungen wiederhergestellt hat, und rollt ihn nun für den Rest aus. Zu diesem Zeitpunkt können Kunden Probleme bei der Authentifizierung gegenüber dem Support-Portal haben.

3. 23. Oktober 2026 um 06:33 UTCresolved

   Der Upstream-Anbieter hat seinen Fix abgeschlossen und der Zugang zum Elastic Support-Portal wurde wiederhergestellt. Kunden können sich wieder beim Support-Portal authentifizieren. Wir betrachten dieses Problem als gelöst und werden keine weiteren Updates bereitstellen. Wenn Sie weiterhin Probleme haben, kontaktieren Sie uns bitte.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. Oktober 2026 um 11:19 UTCinvestigating

   Wir untersuchen ein Problem mit AutoOps für neu erstellte Konten in der AWS us-east-1-Region. Konten, die nach 00:00 UTC am 22. Oktober 2026 erstellt wurden, können möglicherweise nicht auf AutoOps zugreifen und sehen beim Öffnen einen Fehler (HTTP 403). Elastic Cloud Hosted: AutoOps ist für betroffene neue Konten nicht verfügbar. Elastic Cloud Serverless: AutoOps ist für betroffene neue Konten nicht verfügbar. Bestehende Bereitstellungen und Projekte sowie alle anderen Funktionen der Elastic Cloud sind nicht betroffen. Unsere Engineering-Teams arbeiten daran, die Ursache zu identifizieren und den Zugang wiederherzustellen. Wir werden das nächste Update innerhalb von 60 Minuten oder früher bereitstellen, wenn es eine signifikante Änderung gibt

2. 22. Oktober 2026 um 12:00 UTCidentified

   Wir haben die Ursache des Problems identifiziert, das AutoOps betrifft, und stellen einen Fix bereit. Elastic Cloud Hosted und Elastic Cloud Serverless: Kunden, die seit ca. 00:30 UTC am 22. Oktober 2026 ein neues Konto in der AWS us-east-1-Region erstellt haben, konnten nicht auf AutoOps zugreifen und haben möglicherweise einen Fehler (HTTP 403) beim Öffnen gesehen. Der Fix wird jetzt eingeführt, und wir erwarten, dass die Situation bis 13:00 UTC vollständig gelöst ist. Bestehende Bereitstellungen und Projekte sowie alle anderen Funktionen der Elastic Cloud sind nicht betroffen.

3. 22. Oktober 2026 um 20:50 UTCresolved

   Wir haben das Problem mit AutoOps um 12:30 UTC behoben. Elastic Cloud Hosted und Elastic Cloud Serverless: Kunden, die seit ca. 00:30 UTC am 22. Oktober 2026 ein neues Konto in der AWS us-east-1-Region erstellt haben, konnten nicht auf AutoOps zugreifen und haben möglicherweise einen Fehler (HTTP 403) beim Öffnen gesehen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Oktober 2026 um 20:07 UTCinvestigating

   Wir untersuchen ein Problem, das sich auf die Skalierbarkeit bestehender Elastic Cloud Hosted-Bereitstellungen und serverloser Projekte in Azure auswirkt. Neue Projekt- und Bereitstellungserstellung in Azure kann sich verzögern.

2. 20. Oktober 2026 um 21:24 UTCidentified

   Wir haben ein Problem identifiziert, das sich auf die Skalierbarkeit bestehender Elastic Cloud Hosted-Bereitstellungen und serverloser Projekte in Azure auswirkt. Neue Projekt- und Bereitstellungserstellung in Azure kann sich verzögern. Ingenieure arbeiten aktiv daran, das Problem zu mildern.

3. 20. Oktober 2026 um 22:27 UTCmonitoring

   Ingenieure haben ein Problem identifiziert und behoben, das die Skalierbarkeit bestehender Elastic Cloud Hosted-Bereitstellungen und serverloser Projekte in Azure beeinträchtigt. Wir beobachten das Problem, um sicherzustellen, dass der Betrieb normal weitergeht.

4. 21. Oktober 2026 um 03:05 UTCresolved

   Ingenieure haben ein Problem behoben, das die Skalierbarkeit bestehender Elastic Cloud Hosted-Bereitstellungen und serverloser Projekte in Azure beeinträchtigt. Die Skalierung funktioniert wie erwartet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Oktober 2026 um 06:51 UTCinvestigating

   Wir untersuchen ein Problem, das eine Verfügbarkeitszone in der Region GCP europe-west2 (London) betrifft. Ab ca. 06:15 UTC können einige Elastic Cloud Hosted und Serverless-Bereitstellungen mit Kapazität in dieser Zone eine eingeschränkte Verfügbarkeit oder Konnektivität aufweisen. Die Überwachung und Protokollierung von Einsätzen in der Region kann sich ebenfalls verzögern. Einsätze in anderen Zonen und Regionen sind nicht betroffen. Unsere Ingenieure arbeiten aktiv an dem Thema und wir stehen in Kontakt mit unserem Cloud-Anbieter.

2. 20. Oktober 2026 um 07:56 UTCidentified

   Unser Cloud-Provider hat einen Infrastrukturvorfall bestätigt, der eine einzelne Verfügbarkeitszone (europe-west2-b) in der Region GCP europe-west2 (London) betrifft und zu Netzwerkverbindungsverlusten und Ressourcenausfällen in dieser Zone führt. Elastic Cloud Hosted-Bereitstellungen und Elastic Serverless-Projekte mit Ressourcen in der betroffenen Zone können nicht verfügbar sein oder eine beeinträchtigte Leistung aufweisen. Wir haben Schritte unternommen, um zu vermeiden, dass neue Serverless-Projekte in der betroffenen Zone platziert werden, und wir arbeiten daran, Dienste wiederherzustellen, die davon abhängen. Reduzierte Kapazitäten in der Region können die Skalierung und die Schaffung neuer Ressourcen verzögern. Wir haben noch keine geschätzte Zeit für die Wiederherstellung von unserem Cloud-Anbieter. Wir arbeiten eng mit ihnen zusammen und werden das nächste Update innerhalb einer Stunde bereitstellen.

3. 20. Oktober 2026 um 09:15 UTCidentified

   Der Infrastrukturvorfall bei unserem Cloud-Provider, der die Verfügbarkeitszone europe-west2-b in der Region GCP europe-west2 (London) betrifft, dauert an. Elastic Cloud Hosted: Die meisten Bereitstellungen mit Ressourcen in der betroffenen Zone bleiben nicht verfügbar oder degradiert. Wir sehen frühe, begrenzte Anzeichen einer Erholung, und eine kleine Anzahl der ursprünglich betroffenen Einsätze erholt sich. Wir setzen unsere Minderungsarbeit fort und werden mit fortschreitender Erholung mehr teilen. Elastic Serverless: Wir haben Schritte unternommen, um zu vermeiden, dass neue Projekte in der betroffenen Zone platziert werden, und wir balancieren jetzt bestehende Projekte in andere Verfügbarkeitszonen. Wir sehen Anzeichen einer Erholung - einige Projekte sind in der Zwischenzeit nicht verfügbar oder degradiert. Reduzierte Kapazitäten in der Region können die Skalierung und die Schaffung neuer Ressourcen verzögern. Wir haben noch keine geschätzte Zeit für die vollständige Wiederherstellung von unserem Cloud-Anbieter. Wir arbeiten eng mit ihnen zusammen und werden das nächste Update bis 10:15 Uhr UTC bereitstellen.

4. 20. Oktober 2026 um 10:32 UTCidentified

   Der Infrastrukturvorfall bei unserem Cloud-Provider, der die Verfügbarkeitszone europe-west2-b in der Region GCP europe-west2 (London) betrifft, dauert an. Elastic Cloud Hosted-Bereitstellungen und Elastic Serverless-Projekte mit Ressourcen in der betroffenen Zone können nicht verfügbar bleiben oder beeinträchtigt werden. Unsere Teams arbeiten weiterhin an Minderung und Wiederherstellung und wir arbeiten eng mit unserem Cloud-Anbieter zusammen. Wir haben noch keine geschätzte Zeit für eine vollständige Erholung. Wir werden das nächste Update bis 12:00 UTC oder früher bereitstellen, wenn es eine signifikante Änderung gibt.

5. 20. Oktober 2026 um 12:24 UTCidentified

   Der Infrastrukturvorfall bei unserem Cloud-Provider, der die Verfügbarkeitszone europe-west2-b in der Region GCP europe-west2 (London) betrifft, dauert an. Wir sehen leichte Anzeichen einer Erholung, sowohl von unserem Cloud-Anbieter als auch von unserer eigenen Minderungsarbeit. Elastic Cloud Hosted: Einige der betroffenen Bereitstellungen erholen sich. Kunden, deren Planänderungen oder andere Vorgänge während des Vorfalls fehlgeschlagen sind, sollten diese von der Elastic Cloud-Konsole wiederholen. Operationen, die von der betroffenen Zone abhängen, können länger dauern als üblich oder wieder fehlschlagen, bis die Wiederherstellung weiter voranschreitet. Einige Einsätze können nicht verfügbar oder eingeschränkt bleiben. Elastic Serverless: Einige Projekte bleiben möglicherweise nicht verfügbar oder degradiert.

6. 20. Oktober 2026 um 14:15 UTCidentified

   Der Infrastrukturvorfall bei unserem Cloud-Anbieter, der die Verfügbarkeitszone europe-west2-b in der Region GCP europe-west2 (London) betrifft, erholt sich. Unser Cloud-Anbieter meldet die Wiederherstellung von Diensten für die meisten Workloads in der Region, und wir sehen Fortschritte auf unserer Seite, wenn die betroffene Zone zurückkehrt. Elastic Cloud Hosted: Immer mehr betroffene Deployments erholen sich. Kunden, deren Planänderungen oder andere Vorgänge während des Vorfalls fehlgeschlagen sind, sollten diese von der Elastic Cloud-Konsole wiederholen. Einige Bereitstellungen sind möglicherweise immer noch nicht verfügbar oder beeinträchtigt, und einige benötigen möglicherweise zusätzliche Wiederherstellungsschritte, die unser Support-Team von Fall zu Fall durcharbeiten wird. Wenn Ihre Bereitstellung immer noch ungesund ist, wenden Sie sich bitte an den Support. Der Betrieb kann länger dauern als üblich, während die Kapazität wiederhergestellt wird.

7. 20. Oktober 2026 um 17:27 UTCidentified

   Der Infrastrukturvorfall bei unserem Cloud-Anbieter, der die Verfügbarkeitszone europe-west2-b in der Region GCP europe-west2 (London) betrifft, wurde behoben. Wir arbeiten weiter an der vollständigen Wiederherstellung unserer Dienstleistungen. Elastic Cloud Hosted: Immer mehr betroffene Deployments erholen sich. Kunden, deren Planänderungen oder andere Vorgänge während des Vorfalls fehlgeschlagen sind, sollten diese von der Elastic Cloud-Konsole wiederholen. Einige Bereitstellungen sind möglicherweise immer noch nicht verfügbar oder beeinträchtigt, und einige benötigen möglicherweise zusätzliche Wiederherstellungsschritte, die unser Support-Team von Fall zu Fall durcharbeiten wird. Wenn Ihre Bereitstellung immer noch ungesund ist, wenden Sie sich bitte an den Support. Der Betrieb kann länger dauern als üblich, während die Kapazität wiederhergestellt wird.

8. 20. Oktober 2026 um 21:54 UTCresolved

   Der Infrastrukturvorfall bei unserem Cloud-Anbieter, der die Verfügbarkeitszone europe-west2-b in der Region GCP europe-west2 (London) betrifft, wurde behoben. Engineering hat die Wiederherstellung der Infrastruktur abgeschlossen, die in der betroffenen Verfügbarkeitszone läuft. Elastic Cloud Hosted: Kunden, deren Planänderungen oder andere Vorgänge während des Vorfalls fehlgeschlagen sind, sollten diese von der Elastic Cloud-Konsole wiederholen. Einige Bereitstellungen sind möglicherweise immer noch nicht verfügbar oder beeinträchtigt und erfordern möglicherweise zusätzliche Wiederherstellungsschritte, die unser Support-Team von Fall zu Fall durcharbeiten wird. Wenn Ihre Bereitstellung immer noch ungesund ist, wenden Sie sich bitte an den Support.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Oktober 2026 um 16:42 UTCinvestigating

   Wir untersuchen ein Problem, das einige Elastic Cloud Serverless-Projekte in der GCP us-central1-Region betrifft. Kunden können einen verzögerten oder nicht verfügbaren Projektbetrieb erleben.

2. 8. Oktober 2026 um 17:21 UTCidentified

   Wir haben ein Problem mit dem Cloud-Speicher identifiziert, das einige Elastic Cloud Serverless-Projekte in der GCP-Region us-central1 betrifft. Kunden können verzögerte oder nicht verfügbare Projektvorgänge auftreten. Der Anbieter untersucht das Problem und wir überwachen die Wiederherstellung. Wir werden ein weiteres Update bereitstellen, wenn weitere Informationen verfügbar sind.

3. 8. Oktober 2026 um 19:17 UTCidentified

   Einige Elastic Cloud Serverless-Projekte in der GCP us-central1-Region können immer noch verzögerte oder nicht verfügbare Projektoperationen aufweisen. Der Anbieter untersucht das Problem weiter. Wir beobachten die Situation und werden ein weiteres Update bereitstellen, wenn weitere Informationen verfügbar sind.

4. 8. Oktober 2026 um 20:47 UTCmonitoring

   Wir haben Verbesserungen beobachtet, nachdem Minderungsmaßnahmen von unserem Upstream-Cloud-Speicheranbieter angewendet wurden. Einige Elastic Cloud Serverless-Projekte in der GCP us-central1-Region können immer noch verzögerte oder nicht verfügbare Projektoperationen aufweisen, während die Wiederherstellung fortgesetzt wird. Wir beobachten die Situation und werden ein weiteres Update bereitstellen, wenn weitere Informationen verfügbar sind.

5. 9. Oktober 2026 um 00:54 UTCresolved

   Das Upstream-Cloud-Speicherproblem, das einige Elastic Cloud Serverless-Projekte in der GCP-Region us-central1 betrifft, wurde behoben. Der Projektbetrieb hat sich wieder normalisiert, und wir sehen keine betroffenen Projekte mehr in einem roten Gesundheitszustand.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. Oktober 2026 um 14:04 UTCinvestigating

   Kunden mit Serverlosen Projekten in der Region Azure UAE North sehen möglicherweise Verzögerungen bei den in der Cloud-Benutzeroberfläche angezeigten Metriken. Das Team untersucht das Problem und wir werden ein Update in 2 Stunden oder früher veröffentlichen, wenn nötig

2. 6. Oktober 2026 um 17:54 UTCresolved

   Das Problem der metrischen Verfügbarkeit für Serverlose Projekte in Azure UAE North wurde behoben. Verzögerte "Nutzung und Leistung" -Metriken werden jetzt wiederhergestellt, und in die Warteschlange gestellte Nutzungsaufzeichnungen werden verarbeitet. Es wird kein Datenverlust erwartet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. September 2026 um 14:04 UTCinvestigating

   Wir erleben derzeit Verzögerungen bei der Bereitstellung neuer Cloud-Ressourcen aufgrund der Langsamkeit bei einem externen Container-Image-Anbieter. Dies kann zu Verzögerungen beim Erstellen neuer Bereitstellungen, beim Skalieren bestehender oder beim Verlagern von Instanzen führen, die von der Wartung der Infrastruktur betroffen sind. Als Abschwächung können Sie versuchen, fehlgeschlagene Planänderungen erneut auszuführen. Bestehende laufende Bereitstellungen sind nicht betroffen. Unser Team beobachtet die Situation aktiv und arbeitet daran, das Problem zu mildern. Wir werden in den nächsten 12 Stunden ein Update bereitstellen.

2. 23. September 2026 um 16:03 UTCresolved

   Dieses Problem ist gelöst.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 17. September 2026 um 15:50 UTCinvestigating

   Wir untersuchen Berichte über fehlende Metriken auf Knotenebene (CPU, Speicher, Festplatte, Threadpools) für die letzten Zeitbereiche in einer Teilmenge von AutoOps-Regionen. Dies kann als "Keine Daten"-Nachricht in der Nodes-Ansicht erscheinen. Cluster-Gesundheits-, Shard- und Bereitstellungsdaten sind nicht betroffen und es ist kein Datenverlust aufgetreten. Wir werden ein Update innerhalb der nächsten 2 Stunden oder früher bereitstellen.

2. 17. September 2026 um 16:13 UTCidentified

   Wir haben die Ursache der fehlenden Node-Level-Metriken (CPU, Speicher, Festplatte, Thread-Pools) in den betroffenen Regionen identifiziert. Cluster-Gesundheits-, Shard- und Bereitstellungsdaten waren nie betroffen, und es ist kein Datenverlust aufgetreten. Ein Fix wurde in einer Region validiert und wird nun auf die verbleibenden betroffenen Regionen ausgerollt. Wir werden ein weiteres Update bereitstellen, sobald der Rollout abgeschlossen ist.

3. 17. September 2026 um 16:31 UTCresolved

   Das Problem, das fehlende Metriken auf Knotenebene (CPU, Speicher, Festplatte, Threadpools) für die letzten Zeitbereiche in einer Teilmenge von AutoOps-Regionen verursacht, wurde vollständig behoben. Cluster-Gesundheits-, Shard- und Bereitstellungsdaten waren durchweg unberührt und es gingen keine Daten verloren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. September 2026 um 13:17 UTCinvestigating

   Uns ist derzeit bekannt, dass einige Kunden derzeit möglicherweise nicht auf das Elastic Support Portal zugreifen können. Wir arbeiten mit unserem anbieter zusammen, um zu untersuchen. Wenn Sie in der Zwischenzeit den Support kontaktieren müssen, wenden Sie sich bitte an [email protected].

2. 16. September 2026 um 14:49 UTCmonitoring

   Wir sehen Anzeichen einer Erholung auf dem Elastic Support Portal, und Kunden sollten jetzt wie gewohnt zugreifen können. Wir werden die Überwachung für 30 Minuten fortsetzen, bevor wir diesen Vorfall als gelöst markieren.

3. 16. September 2026 um 15:38 UTCresolved

   Das Elastic Support Portal bleibt verfügbar und stabil - zu diesem Zeitpunkt betrachten wir diesen Vorfall gelöst.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 12. September 2026 um 23:21 UTCinvestigating

   Wir untersuchen Metrikverzögerungen in der Konsole.

2. 13. September 2026 um 00:18 UTCidentified

   Wir haben die Ursache der Verzögerung der Metriken identifiziert und behoben. Die Warteschlange wird verarbeitet und verzögerte Metriken können nach Abschluss angezeigt werden.

3. 13. September 2026 um 02:55 UTCmonitoring

   Metrik-Warteschlangen werden verarbeitet und verzögerte Daten beginnen sich wieder zu zeigen. Wir werden überwachen, um sicherzustellen, dass alles wie erwartet aufholt.

4. 13. September 2026 um 07:45 UTCresolved

   Die Metriken Einnahmeverzögerung in GCP us-east4 wurde vollständig behoben. Alle in die Warteschlange gestellten Daten wurden verarbeitet und die Metriken werden nun in Echtzeit in der Konsole angezeigt.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. September 2026 um 01:30 UTCidentified

   Wir haben einen Fehler in unserer Berechtigungsverwaltungsoberfläche identifiziert und sind dabei, ihn zu beheben und zu mindern, der verhindert, dass Benutzer mit der Rolle des Organisationsbesitzers und der Cloud-Konsole, Elasticsearch und Kibana-Zugriff auf Kibana in Hosted Deployments zugreifen können.

2. 10. September 2026 um 06:03 UTCidentified

   Update: Dieser Vorfall dauert noch an und wir werden weiter untersuchen.

3. 10. September 2026 um 09:51 UTCmonitoring

   Update: Der Fix wurde in der Produktion bereitgestellt und wir haben eine Datenkorrektur für betroffene Konten vorgenommen, um den Kibana-Zugang für betroffene Benutzer wiederherzustellen. Wir überwachen, um eine vollständige Auflösung zu bestätigen.

4. 10. September 2026 um 22:31 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 9. September 2026 um 20:44 UTCidentified

   Wir haben einen Fehler in Fleet Server 9.5.3 (ebenfalls in 9.4.6 vorhanden) identifiziert, der dazu führen kann, dass Elastic Agents abstürzen und offline gehen, wenn Fleet ein Konfigurationsupdate, einschließlich der Registrierung, einer Richtlinienänderung oder einer routinemäßigen Revisionsbeule, ausführt. Dies wirkt sich nur auf Richtlinien aus, die die Remote-Elasticsearch-Ausgabefunktion von Fleet verwenden. Empfehlung: Wenn Sie die Elasticsearch-Fernausgabe von Fleet verwenden, aktualisieren Sie nicht auf 9.5.3 oder 9.4.6, bis eine feste Version verfügbar ist. Wenn Sie sich bereits in einer betroffenen Version befinden und Fehler beim Agenten-Check-in auftreten, wenden Sie sich an den Support für Behebungsschritte. Ein Fix wurde zusammengeführt und wird in den nächsten 9.5.x und 9.4.x Releases ausgeliefert. Bekannte Problemdokumentation: Fleet-Server#7791, Elastic-Agent#16542.

2. 11. September 2026 um 14:25 UTCidentified

   Wir haben Fleet Server-Versionen 9.5.3 und 9.4.6 mit korrigierten Releases ab dem 10. September 2026 um 21:20 Uhr UTC gepatcht. Ein Upgrade auf die aktuellen Versionen 9.4.6 oder 9.5.3 ist von diesem Fehler nicht betroffen, da die aktualisierte Version den Fix enthält. - Wenn Sie am 10. September 2026 vor 21:20 Uhr UTC auf 9.4.6 oder 9.5.3 aktualisiert haben, führen Sie die folgende Minderung durch: 1. Erzwingen Sie einen Neustart der Integration Server-Komponente der betroffenen Bereitstellung 2. Durchführung von Bereinigungsverfahren für betroffene Elastic Agents (siehe https://support.elastic.co/knowledge/bee1c75c) — erforderlich, wenn Agenten nach dem Neustart des Integration Servers nicht einchecken konnten oder offline blieben

3. 11. September 2026 um 16:00 UTCidentified

   Wir haben Fleet Server-Versionen 9.5.3 und 9.4.6 mit korrigierten Releases ab dem 10. September 2026 um 21:20 Uhr UTC gepatcht. Ein Upgrade auf die aktuellen Versionen 9.4.6 oder 9.5.3 ist von diesem Fehler nicht betroffen, da die aktualisierte Version den Fix enthält. - Wenn Sie am 10. September 2026 vor 21:20 Uhr UTC auf 9.4.6 oder 9.5.3 aktualisiert haben, führen Sie die folgende Minderung durch: 1. Erzwingen Sie einen Neustart der Integration Server-Komponente der betroffenen Bereitstellung 2. Durchführung von Bereinigungsverfahren für betroffene Elastic Agents (siehe https://support.elastic.co/knowledge/bee1c75c) — erforderlich, wenn Agenten nach dem Neustart des Integration Servers nicht einchecken konnten oder offline blieben WICHTIG: Der gepatchte Fleet Server ist außerhalb von Elastic Cloud Enterprise (ECE) Stack Packs und Elastic Cloud Hosted (ECH) nicht verfügbar.

4. 17. September 2026 um 10:30 UTCresolved

   Wir haben bestätigt, dass bei Elastic Agents keine Registrierungsfehler mehr auftreten. Corrected Fleet Server Releases (9.5.4 / 9.4.6) sind seit dem 10. September 2026 auf Elastic Cloud Hosted und Elastic Cloud Enterprise Stack Packs verfügbar, und alle bekannten betroffenen Bereitstellungen haben die Wiederherstellung bestätigt. Wenn Sie vor diesem Zeitpunkt ein Upgrade auf eine betroffene Version durchgeführt haben und die Minderung noch nicht angewendet haben, finden Sie hier eine Anleitung: https://support.elastic.co/knowledge/bee1c75c.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 2. September 2026 um 00:04 UTCresolved

   Von 21:50 bis 23:42 UTC stießen wir auf erhöhte Fehlerraten für Anthropic Claude Haiku 4.5, OpenAI GPT-5.6 und Google Gemini 2.5 Flash mit dem Elastic Inference Service in EU-Regionen. Dieses Problem ist nun gelöst.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. September 2026 um 15:18 UTCinvestigating

   Wir untersuchen derzeit ein Problem, das sich auf Dienste auswirkt, die in GCP us-central1 ausgeführt werden. Wir werden zusätzliche Updates bereitstellen, wenn wir mehr über den Umfang der Auswirkungen erfahren.

2. 1. September 2026 um 15:51 UTCidentified

   Ein anhaltendes Problem betrifft Dienste, die in GCP us-central1 ausgeführt werden. Dies umfasst, ist aber nicht beschränkt auf Elastic Cloud Hosted und Serverless Projekte in der Region und unseren Docker Registry Service. Wir beobachten die Situation weiterhin und werden Updates bereitstellen, sobald sie verfügbar sind.

3. 1. September 2026 um 16:15 UTCidentified

   Ein anhaltendes Upstream-CSP-Problem betrifft Dienste, die in GCP us-central1 ausgeführt werden. Dies umfasst, ist aber nicht beschränkt auf Elastic Cloud Hosted und Serverless Projekte in der Region und unseren Docker Registry Service. Wir beobachten die Situation weiterhin und werden Updates bereitstellen, sobald sie verfügbar sind.

4. 1. September 2026 um 16:22 UTCmonitoring

   Wir sehen Anzeichen einer Erholung für Dienste in GCP us-central1, die von einem vorgelagerten CSP-Problem betroffen sind. Wir beobachten die Situation weiterhin und werden Updates bereitstellen, sobald sie verfügbar sind.

5. 1. September 2026 um 20:05 UTCresolved

   Dieses Problem ist gelöst.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. September 2026 um 08:16 UTCinvestigating

   Wir sind uns eines Fehlers bewusst, der sich auf Kunden der Elasticsearch-Versionen 9.5.0, 9.5.1 und 9.5.2 auswirkt, bei denen Bulk-Index-Operationen, die auf dem primären Shard verarbeitet werden, zu Abweichungen bei den Replikaten führen können, was zu einer hohen Festplattennutzung und langfristigen Wiederherstellungen führt. Das Team arbeitet an einem Fix. Weitere Informationen finden Sie unter https://www.elastic.co/docs/release-notes/elasticsearch/known-issues#elasticsearch-9.5.2-known-issues Das nächste Update wird in den nächsten 2 Stunden oder früher sein, wenn nötig.

2. 1. September 2026 um 11:07 UTCidentified

   Wir haben die Ursache identifiziert und das Team arbeitet an einem Fix, der in Elasticsearch Version 9.5.3 veröffentlicht werden soll. Was Sie tun können: - Wenn Sie noch nicht auf 9.5.* aktualisiert haben, sind Sie nicht betroffen, da Upgrades auf 9.5 deaktiviert wurden, bis 9.5.3 freigegeben ist - Wenn Sie bereits 9.5 ausführen und die Symptome dieses Problems auftreten, wenden Sie sich bitte an Elastic Support. Weitere Informationen finden Sie unter https://www.elastic.co/docs/release-notes/elasticsearch/known-issues#elasticsearch-9.5.2-known-issues

3. 1. September 2026 um 15:46 UTCidentified

   Der Fix wurde identifiziert und in den Patch-Zweig von Elasticsearch 9.5 zurückportiert. Die Teams führen die erforderlichen Validierungen durch, bevor sie das 9.5.3-Release planen und ausrollen.

4. 3. September 2026 um 12:13 UTCmonitoring

   Elasticsearch 9.5.3 wurde veröffentlicht und allen Kunden, die derzeit 9.5.0, 9.5.1 oder 9.5.2 ausführen, wird empfohlen, so schnell wie möglich auf diese neue Version zu aktualisieren.

5. 3. September 2026 um 15:47 UTCmonitoring

   Elasticsearch 9.5.3 wurde veröffentlicht und allen Kunden, die derzeit 9.5.0, 9.5.1 oder 9.5.2 ausführen, wird empfohlen, so schnell wie möglich auf diese neue Version zu aktualisieren. Betroffenen Kunden wird empfohlen, die Workaround-Schritte von https://github.com/elastic/elasticsearch/issues/158212 nach dem Upgrade zu befolgen.

6. 30. September 2026 um 20:44 UTCresolved

   Dieses Problem wurde in der Version 9.5.3 von Elasticsearch behoben. Kunden, die die Versionen 9.5.0, 9.5.1 oder 9.5.2 von Elasticsearch verwenden, wird empfohlen, so schnell wie möglich auf eine neuere Version zu aktualisieren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 27. August 2026 um 17:11 UTCmonitoring

   Am 26. August, gegen 00:00 Uhr UTC, haben wir eine Änderung in Managed Inputs implementiert, die einige Regeln in unserem internen DNS-Provider beeinflusst hat, indem wir die .apm-Endpunkte einiger unserer Serverless-Kunden entfernt haben. Der Service wurde um 9 Uhr UTC am selben Tag wiederhergestellt. Während dieser Zeit hätten einige Kunden die Nichtverfügbarkeit des .apm-Endpunkts für einen Zeitraum im 9-Stunden-Fenster erlebt. Wir führen einige Kontrollen und Warnungen ein, um sicherzustellen, dass sich dies nicht wiederholt.

2. 27. August 2026 um 18:33 UTCresolved

   Dies ist jetzt gelöst

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. August 2026 um 20:22 UTCinvestigating

   Wir untersuchen derzeit erhöhte Fehlerquoten, die das verwaltete OTLP auf Elastic Cloud Serverless betreffen. Unser Team untersucht aktiv die Ursache. Wir werden innerhalb von 30 Minuten ein Update bereitstellen.

2. 20. August 2026 um 20:53 UTCinvestigating

   Wir untersuchen weiterhin erhöhte Fehlerquoten bei Managed OTLP auf Elastic Cloud Serverless. Wir werden innerhalb von 1 Stunde ein Update bereitstellen.

3. 20. August 2026 um 21:59 UTCidentified

   Wir haben die Ursache für die erhöhten Fehlerquoten bei serverlos verwaltetem OTLP identifiziert. Eine Abschwächung wurde angewendet und wir überwachen, um zu bestätigen, dass die Fehlerquoten wieder zum Ausgangswert zurückkehren. Aufgrund unserer Untersuchung waren die Workloads der Kunden nicht betroffen.

4. 20. August 2026 um 22:13 UTCresolved

   Dieser Vorfall wurde behoben. Die Ursache wurde identifiziert und angegangen. Die Workloads der Kunden waren während dieses Vorfalls nicht betroffen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. August 2026 um 12:48 UTCinvestigating

   Es wurde ein Problem identifiziert, das die Erstellung neuer Serverless-Projekte in der Eastus-Region von Azure betrifft. Unser Team untersucht aktiv, um die Ursache zu bestimmen. Wir werden innerhalb der nächsten Stunde oder sobald die Ursache festgestellt wurde, eine Statusaktualisierung durchführen, je nachdem, was zuerst eintritt.

2. 20. August 2026 um 14:05 UTCmonitoring

   Wir haben festgestellt, dass das Problem auf ein Upstream-Problem mit der Speicherkomponente von Azure zurückzuführen ist. Bei der Prüfung beschränken sich die Auswirkungen strikt auf neue Projektinitialisierungszeiten, was zu längeren Erstellungszeiten für Serverlose Projekte in der Azure-Eastus-Region führt. Wir werden ein weiteres Update bereitstellen, sobald das Problem behoben ist.

3. 20. August 2026 um 16:22 UTCresolved

   Die Speicherkomponentenprobleme von Azure in der Eastus-Region wurden behoben. Folglich sind die Serverless-Projekterstellungszeiten wieder normal und funktionieren wie erwartet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. August 2026 um 09:22 UTCidentified

   Elasticsearch 9.5.1 enthält ein bekanntes Problem, bei dem boolesche Abfragen, die eine Must-, Filter- oder Soll-Klausel mit einer Multi-Wert-Begriffsabfrage enthalten, neben einer Must not-Klausel in Feldern mit deaktivierter Indexierung immer noch falsch-positive Übereinstimmungen zurückgeben können. Während der Patch in 9.5.1 (https://github.com/elastic/elasticsearch/pull/155936) den Bulk-Scorer-Defekt für Term- und Range-Abfragepfade behoben hat; Multi-Value-Begriffsabfragen verwenden einen anderen Lucene-Abfragetyp, der nicht von diesem Fix abgedeckt wurde. Zeitreihendatenströme (TSDB) und spaltenförmige Indizes/Datenströme bleiben für dieses Abfragemuster betroffen, da die Indexierung in diesen Feldern standardmäßig deaktiviert ist. Betroffene Begriffsabfragen können falsch-positive Übereinstimmungen (einschließlich Dokumente, die hätten ausgeschlossen werden sollen) zurückgeben und höhere Dokumentzahlen als erwartet melden. Es wird kein Fehler ausgelöst, so dass Abfragen erfolgreich abgeschlossen zu sein scheinen. Was Sie tun können: - Wenn Sie noch nicht auf 9.5.* aktualisiert haben, empfehlen wir, das Upgrade zu verschieben, bis Version 9.5.2 verfügbar ist. - Wenn Sie bereits 9.5.* ausführen, wenden Sie sich an Elastic Support, wenn Sie Hilfe benötigen, um festzustellen, ob Ihre Suchanfragen betroffen sind. Wir haben die Ursache identifiziert, ein Fix ist im Gange und wir bereiten eine Patch-Veröffentlichung vor. Wir werden ein weiteres Update bereitstellen, wenn der Fix fertig ist.

2. 20. August 2026 um 17:09 UTCresolved

   Elasticsearch 9.5.2 wurde veröffentlicht und enthält den Fix für dieses Problem. Kunden, die 9.5.0 oder 9.5.1 ausführen, sollten auf 9.5.2 upgraden. Zu diesem Zeitpunkt betrachten wir dieses Problem als gelöst und werden keine weiteren Updates bereitstellen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. August 2026 um 08:32 UTCinvestigating

   Wir sehen erhöhte Fehlerquoten beim Upstream-Anbieter für das microsoft-multilingual-e5-große Einbettungsmodell. Das Einbetten von Suchanforderungen in dieses Modell kann fehlschlagen. Wir untersuchen

2. 13. August 2026 um 14:45 UTCinvestigating

   Wir sehen eine gewisse Verbesserung der Verfügbarkeit, beobachten aber weiterhin die Situation. Wir werden zu gegebener Zeit weitere Informationen vorlegen.

3. 13. August 2026 um 18:26 UTCmonitoring

   Leider können wir das E5 Multilingual Large-Modell im Elastic Inference Service aufgrund fortgesetzter Upstream-Provider-Probleme nicht mehr unterstützen. Alle Kunden, die dieses Modell benötigen, sollten benutzerdefinierte Inferenzendpunkte mit ihren eigenen API-Schlüsseln einrichten.

4. 17. August 2026 um 11:40 UTCresolved

   Das microsoft-mehrsprachige e5-große Modell wurde vom Elastic Inference Service zurückgezogen. Anfragen an dieses Modell geben nun einen Fehler zurück. Kunden, die dieses Modell mit Elastic Cloud verwenden möchten, müssen mit ihrem eigenen API-Schlüssel einen benutzerdefinierten Inferenz-Endpunkt erstellen. Weitere Einzelheiten finden Sie in unserer Inferenzdokumentation: https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-inference

Automatisch aus der offiziellen Störungsmeldung übersetzt.