Störungsverlauf von Render

1. 24. Oktober 2026 um 07:11 UTCidentified

   Transaktions-E-Mails für Plattformereignisse, einschließlich, aber nicht beschränkt auf neue Konto-Anmelde-E-Mail-Bestätigungen, Service Build / Bereitstellung von Fehlerbenachrichtigungen, Passwort-Resets usw. senden derzeit nicht. Wir befassen uns derzeit mit diesem Thema.

2. 24. Oktober 2026 um 07:30 UTCmonitoring

   Wir haben einen Fix angewendet und sehen, dass Nachrichten erfolgreich geliefert werden. Wir beobachten weitere Fragen.

3. 24. Oktober 2026 um 07:41 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. Oktober 2026 um 16:05 UTCidentified

   Wir haben eine verschlechterte Netzwerkleistung in Verbindung mit einem Upstream-Anbieter identifiziert - wir werden hier weiterhin Updates bereitstellen.

2. 23. Oktober 2026 um 16:10 UTCidentified

   Wir arbeiten weiter an einer Lösung für dieses Problem.

3. 23. Oktober 2026 um 16:14 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 23. Oktober 2026 um 17:34 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Oktober 2026 um 20:48 UTCinvestigating

   Wenn das Klonen fehlschlägt, wird das Deployment fehlschlagen. Deploy Logs liefern Fehler im Zusammenhang mit diesem Fehler. Das Wiederholen eines Deployments kann erfolgreich sein. Wir untersuchen derzeit dieses Problem.

2. 20. Oktober 2026 um 21:16 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 20. Oktober 2026 um 23:46 UTCidentified

   Wir arbeiten weiter an einer Lösung für dieses Problem.

4. 21. Oktober 2026 um 00:08 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

5. 21. Oktober 2026 um 00:29 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Oktober 2026 um 20:58 UTCidentified

   Wir haben ein Problem mit einem Upstream-Cloud-Anbieter identifiziert, das Echtzeit-Updates bei Rendern beeinflusst. Seit ca. 19:10 UTC: - Dashboard: Bereitstellungsstatus, Dienstereignisse sowie Status für die Ausführung von Diensten und Aufgaben werden möglicherweise nicht automatisch aktualisiert. Aktualisieren Sie die Seite, um den aktuellen Zustand zu sehen. SDK-Aufrufe, die darauf warten, dass ein Task ausgeführt wird, können nach etwa 60 Sekunden mit einem 500-Fehler fehlschlagen. Die Aufgabe läuft selbst laufen und normal abschließen. Um den Status eines Task-Runs zu überprüfen, verwenden Sie GET /v1/task-runs/{taskRunId}. Bereitstellungen, laufende Dienste, Datenbanken und Protokolle sind nicht betroffen.

2. 15. Oktober 2026 um 21:53 UTCmonitoring

   Unser Upstream-Anbieter hat das Problem behoben und die betroffenen Render-Dienste haben sich erholt. Wir beobachten weiter.

3. 16. Oktober 2026 um 01:12 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. Oktober 2026 um 19:32 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 14. Oktober 2026 um 19:45 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 14. Oktober 2026 um 19:47 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

4. 14. Oktober 2026 um 20:41 UTCmonitoring

   Wir unterbrechen vorübergehend die Bereitstellung von kostenlosen Diensten.

5. 14. Oktober 2026 um 20:55 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

6. 14. Oktober 2026 um 20:57 UTCidentified

   Builds starten in allen Regionen nicht wieder und unser Team arbeitet immer noch daran, die Ursache zu beheben. Die Bereitstellung von kostenlosen Diensten bleibt angehalten. Wir werden ein weiteres Update teilen, sobald wir mehr Informationen haben.

7. 14. Oktober 2026 um 21:43 UTCmonitoring

   Es wurde ein Fix implementiert, und wir überwachen die Ergebnisse. Bereitstellungen und Builds für Dienste, die auf freien Instanzen laufen, werden weiterhin angehalten.

8. 14. Oktober 2026 um 22:18 UTCresolved

   Dieser Vorfall wurde behoben.

9. 22. Oktober 2026 um 17:58 UTCpostmortem

   ### Zusammenfassung Am 14. Oktober 2026, zwischen 12:12 und 15:08 PDT (19:12 - 22:08 UTC), konnten Builds und Deployments in allen Regionen nicht starten, ins Stocken geraten oder verzögerten sich signifikant während zweier Aufprallperioden von insgesamt etwa 2 Stunden und 20 Minuten. Ursache war eine Datenbankschema-Migration im Rahmen eines geplanten Versions-Upgrades unseres internen Jobplaners, der Builds, Deployments und andere kritische Plattformoperationen koordiniert. Die Migration führte zu einer hohen Belastung und einer länger als erwarteten Wiederherstellungszeit der Datenbank dieses Systems. Wir werden in Zukunft ändern, wie wir Upgrades und Modifikationen dieses Systems in einer hochverfügbaren Weise durchführen, so dass eine ähnliche Änderung keinen Ausfall mehr verursachen kann. ### Auswirkungen Es gab zwei Perioden der Auswirkungen. Während dieser Zeit waren die Live-Benutzerdienste nicht betroffen, aber Builds und Deployments in allen Regionen konnten nicht gestartet, nicht abgeschlossen oder erheblich verzögert werden. **Periode 1: 12: 12 - 12: 40 PDT \(19: 12 - 19: 40 UTC\), ca. 28 Minuten ** * Neue Builds und Deploys wurden nicht gestartet. Deploys in Progress ist zum Stillstand gekommen. * Einige Anforderungen zum Erstellen eines Deployments über Dashboard, API und CLI haben Fehler zurückgegeben (HTTP 500). **Teilwiederherstellung: 12:40 - 13:18 PDT \(19:40 - 20:18 UTC\)** * Builds und Deploys liefen, aber Deploys brauchten etwa 20 Sekunden, um zu starten, anstatt ein paar hundert Millisekunden. **Period 2: 13:18 - 15:08 PDT \(20:18 - 22:08 UTC\), ca. 1 Stunde 50 Minuten ** * Builds und Deployments wurden verzögert, im laufenden \(einschließlich in Pre-Deploy\) blockiert oder fehlgeschlagen. Ab 13:51 PDT konnten fast keine neuen Builds starten. * Einige Warteschlangen-Bereitstellungen wurden nach der Wiederherstellung nicht gestartet, und das Abbrechen über die API hatte keine Auswirkungen. Benutzer mussten diese Bereitstellungen erneut versuchen. ### Wurzelursache Render verwendet ein internes Job-Scheduler-System, um Builds, Deployments und andere kritische Plattformoperationen zu koordinieren. Wir haben Verbesserungen an der Verteilung der Arbeit eingeführt und ein geplantes Versionsupgrade dieses Systems in der Produktion nach einer erfolgreichen Praxis in einer Testumgebung begonnen. Das Upgrade beinhaltete eine Datenbankschema-Migration, die eine große Tabelle sperrte und die CPU-Auslastung der Datenbank auf 100% erhöhte. Diese Datenbank speichert sowohl den Kernjobstatus des Systems als auch Sekundärdaten, die für die Suche und Berichterstattung verwendet werden. Das System konnte den Jobzustand nicht zuverlässig lesen oder schreiben, so dass Builds und Deployments gestoppt oder verlangsamt wurden. Ingenieure wurden schnell auf das Problem aufmerksam gemacht und das Upgrade rückgängig gemacht. Drei Faktoren erweiterten jedoch die Auswirkungen: * Ein Pre-Upgrade-Schritt zum Erstellen eines Datenbankklons für das Rollback konnte aufgrund eines Fehlers des zugrunde liegenden Cloud-Anbieters nicht abgeschlossen werden, so dass ein schnelles Rollback nicht verfügbar war. * Die Migration lief in der Datenbank weiter, nachdem der Client, der das Upgrade durchführte, gestoppt und das Upgrade rückgängig gemacht wurde. Es wurde um 13:49 PDT gefunden und beendet, etwa 1,5 Stunden nach dem Start. * Ein Versuch, der Datenbank Kapazität hinzuzufügen, ist aufgrund eines Fehlers des zugrunde liegenden Cloud-Anbieters fehlgeschlagen. ### Timeline Alle Zeiten sind PDT auf 2026-10-14 \(UTC-7\). * **12:13** - Das Upgrade wird gestartet, einschließlich der Migration des Datenbankschemas. Die Datenbanklast steigt und Builds und Deployments stoppen den Start. * **12:24** - Auswirkungen auf Builds und Deployments identifiziert. Der Vorfall eskalierte. * **12:33** - Statusseite Vorfall geöffnet. * **12:34** - Ingenieure setzen das Upgrade zurück und stoppen den Client, der die Schemamigration durchführt. * **12:37** - Job-Scheduler-System erholt. Erstellen und Bereitstellen von Lebensläufen mit langsameren Startzeiten. Ende von Periode 1. * **13:17** - Ingenieure starten eine ungesunde Instanz des Systems neu, um die Last auszugleichen. Datenbankverbindungen und Fehler nehmen im gesamten System zu. Beginn der 2. Periode. * **13:37** - Free-Tier-Bereitstellungen angehalten, um die Last zu reduzieren. * **13:49** - Ingenieure finden die Schema-Migration noch in der Datenbank und beenden sie. * **14:16** - Datenbank neu gestartet. Ein Versuch, Datenbankkapazität hinzuzufügen, scheitert an einem Fehler des zugrunde liegenden Cloud-Anbieters. * **14:27** - Verbleibende Komponenten des Systems neu gestartet. * **14:30** - Builds und Bereitstellungen beginnen sich zu erholen, wobei die Build- und Bereitstellungszeiten langsamer als üblich sind, wenn der Backlog verarbeitet wird. * **15:08** - Die Bereitstellung der Startzeiten kehrt zum Normalzustand zurück und das Laden der Datenbank kehrt zum Niveau vor dem Vorfall zurück. Ende von Periode 2. * **15:11** - Free-Tier-Bereitstellungen und Spin-ups werden allmählich wieder aktiviert. * **15:18** - Vorfall gelöst. ### Mitigationen **Erledigt während des Vorfalls** * Das Upgrade der Job-Scheduler-Komponente und die Konfigurationsänderung wurde rückgängig gemacht (12:34 PDT). * Angehaltene Free-Tier-Bereitstellungen und Spin-ups, um die Last zu reduzieren, und dann nach der Wiederherstellung schrittweise wieder aktiviert. * Beendete die Schemamigration, die noch in der Datenbank ausgeführt wurde \(13:49 PDT\). * Die Datenbank und das Jobplaner-System wurden neu gestartet, um den normalen Betrieb wiederherzustellen. * Unterbrach das Upgrade in der Produktion, bis der Upgrade-Prozess geändert wurde. **Im Gange \(gestartet während des Vorfalls \)** * Diese Datenbank wird aktualisiert, um die zonenübergreifende hohe Verfügbarkeit zu unterstützen. ** Geplant** * Implementierung einer neuen Upgrade- und Deployment-Praxis für diese Komponente: Wir werden blau-grüne Deployments implementieren, um ein Upgrade dieses Systems unter Last in Zukunft zu vermeiden. * Passen Sie die zugrunde liegenden Speichermechanismen für den Jobplaner an, um besser für diesen Workload-Typ geeignet zu sein, nachdem wir Blue-Green-Bereitstellungen implementiert haben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 3. Oktober 2026 um 19:35 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 3. Oktober 2026 um 19:53 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 3. Oktober 2026 um 20:13 UTCmonitoring

   Die betroffenen Komponenten erholen sich. Wir beobachten die Situation.

4. 3. Oktober 2026 um 20:21 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 27. September 2026 um 01:24 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 27. September 2026 um 01:36 UTCmonitoring

   Unser Upstream-Anbieter hat begonnen, sich zu erholen. Die dienste in oregon verbessern sich und wir überwachen weiterhin.

3. 27. September 2026 um 02:17 UTCmonitoring

   Alle dienste, mit ausnahme der kostenlosen webdienste, haben sich erholt. Wir beobachten weiter.

4. 27. September 2026 um 03:01 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. September 2026 um 18:26 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 25. September 2026 um 18:38 UTCresolved

   Builds und Deployments sind für eine Teilmenge von Diensten in Oregon fehlgeschlagen. Dienste mit einem vorgefertigten Docker-Image und statischen Sites waren nicht betroffen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. September 2026 um 23:36 UTCresolved

   Gegen 23:31 UTC am 2026-09-23 wurden Key Value-Dienste, die vor 2024-03-05 erstellt wurden, aufgrund einer Konfigurationsänderung auf unserer Seite versehentlich neu gestartet. Es werden keine weiteren Neustarts als Folge dieser Änderung geplant oder erwartet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 9. September 2026 um 21:26 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 9. September 2026 um 21:32 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 9. September 2026 um 21:34 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

4. 9. September 2026 um 21:38 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 2. September 2026 um 17:19 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 2. September 2026 um 17:30 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 2. September 2026 um 17:40 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. August 2026 um 20:24 UTCresolved

   Einige Webdienste in Oregon waren zwischen 19:20 und 19:30 UTC nicht verfügbar.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. August 2026 um 15:47 UTCinvestigating

   Wir untersuchen Service-Instabilität, die einige Web-Services in unserer Region Singapur betrifft. Kunden können unerwartete Service-Neustarts oder intermittierende Verfügbarkeit erleben. Unser Team untersucht und arbeitet aktiv daran, den normalen Betrieb wiederherzustellen. Wir werden ein Update bereitstellen, sobald weitere Informationen verfügbar sind.

2. 31. August 2026 um 16:08 UTCinvestigating

   Wir haben beobachtet, dass Bereitstellungen in erster Linie davon betroffen sind.

3. 31. August 2026 um 16:33 UTCinvestigating

   Der eingehende Verkehr zu den Diensten in Singapur ist betroffen. Kostenlose Service-Spin-ups (aus dem Leerlauf) in Singapur wurden vorübergehend deaktiviert, während wir weiter untersuchen.

4. 31. August 2026 um 17:22 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

5. 31. August 2026 um 18:09 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. August 2026 um 15:47 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 20. August 2026 um 16:12 UTCidentified

   Ein Problem wurde mit unserem Upstream-Anbieter Google Cloud identifiziert. Kostenlose Webdienste: Builds/Deployments und Spin-up wurden vorübergehend deaktiviert, während wir daran arbeiten, das Problem zu beheben.

3. 20. August 2026 um 17:27 UTCmonitoring

   Wir beobachten die Wiederherstellung von Builds und Deployments in allen Regionen. Builds, Deployments und Spin-up für kostenlose Webdienste wurden neu aktiviert. Einige Kunden können weiterhin eine erhöhte Latenz sehen, während die Wiederherstellung fortschreitet. Wir beobachten weiter.

4. 20. August 2026 um 17:45 UTCmonitoring

   Wir haben eine vollständige Erholung beobachtet. Wir beobachten weiterhin alle weiteren Fragen.

5. 20. August 2026 um 19:40 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 27. Juli 2026 um 14:43 UTCinvestigating

   Anfragen über das Dashboard können langsamer als üblich sein. Wir untersuchen derzeit das Problem.

2. 27. Juli 2026 um 17:59 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 27. Juli 2026 um 18:27 UTCinvestigating

   Auch die REST-API erfährt eine verschlechterte Leistung. Infolgedessen kann es bei Anfragen zu Timeouts kommen und Sie müssen Ihre Anfrage möglicherweise wiederholen. Wir untersuchen weiter.

4. 27. Juli 2026 um 20:18 UTCmonitoring

   Wir haben einen Fix implementiert und überwachen die Ergebnisse. Die Bereitstellung von Fehlergründen ist vorübergehend nicht verfügbar. Deploy-Fehlerereignisse werden weiterhin generiert. Wir werden ein Update bereitstellen, sobald die Fehlergründe für die Bereitstellung erneut aktiviert sind.

5. 27. Juli 2026 um 23:58 UTCmonitoring

   Seit unseren Fixes wurden keine weiteren Probleme beobachtet. Das Dashboard und die REST API bleiben voll funktionsfähig. Deploy-Fehlergründe sind weiterhin deaktiviert. Wir werden diesen Vorfall aktualisieren, sobald sie wieder aktiviert sind. Für heute werden keine weiteren Updates erwartet (2026-07-27, UTC-7).

6. 28. Juli 2026 um 19:35 UTCresolved

   Wir haben weiterhin keine weiteren Probleme beobachtet und die Gründe für den Einsatzfehler wurden erneut aktiviert.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. Juli 2026 um 11:16 UTCinvestigating

   Wir untersuchen ein infrastrukturproblem, das dienste betrifft, die in unserer region oregon gehostet werden. Einige Dienste können nicht erreichbar sein oder fehlgeschlagene Anfragen auftreten. Unser Ingenieurteam arbeitet aktiv daran, die Ursache zu identifizieren und den normalen Betrieb wiederherzustellen.

2. 24. Juli 2026 um 11:27 UTCmonitoring

   Wir haben eine Erholung bei allen Diensten beobachtet und beobachten jetzt die Situation.

3. 24. Juli 2026 um 11:44 UTCmonitoring

   Wir glauben, dass das Problem von einem Upstream-Anbieter verursacht wurde. Wir beobachten die Situation weiter.

4. 24. Juli 2026 um 13:30 UTCresolved

   Dieser Vorfall ist nun behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Juli 2026 um 00:41 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 20. Juli 2026 um 00:55 UTCidentified

   GitHub meldet weiterhin einen Ausfall, https://www.githubstatus.com. Dies führt zu Authentifizierungsfehlern beim Versuch, von einem GitHub-Repository aus bereitzustellen.

3. 20. Juli 2026 um 01:54 UTCmonitoring

   Wir sehen jetzt eine Erholung unserer Build-Ausfallrate. Wir verfolgen die Angelegenheit weiterhin.

4. 20. Juli 2026 um 02:11 UTCresolved

   Die Fehlerraten von Builds haben sich erholt. Lösung.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 19. Juli 2026 um 03:44 UTCinvestigating

   Wir haben eine erhöhte Anzahl von Berichten über Git-Klon-Fehler erhalten, die zu einem 403-Fehler führen und den Einsatz abbrechen. Wir untersuchen.

2. 19. Juli 2026 um 03:55 UTCidentified

   Dienste, die nicht eingesetzt werden, sind die in Frankfurt. Laufende Dienste sind nicht betroffen, nur der Bereitstellungsprozess schlägt fehl. Wir arbeiten immer noch daran, die Ursache dieses Fehlers für diese Dienste zu ermitteln.

3. 19. Juli 2026 um 05:57 UTCidentified

   Benutzer mit in Frankfurt gehosteten Diensten, die auf GitHub-Repositories für Bereitstellungen angewiesen sind, sehen weiterhin 403 Fehler in ihren Protokollen, die dazu führen, dass die Bereitstellung fehlschlägt. Wir arbeiten weiter an diesem Thema in unseren eigenen Systemen und haben GitHub kontaktiert.

4. 19. Juli 2026 um 08:29 UTCidentified

   Wir arbeiten weiter daran, dieses Problem zu mildern, während wir auch mit GitHub zusammenarbeiten, um diese Bereitstellungsfehler zu beheben.

5. 19. Juli 2026 um 09:10 UTCmonitoring

   Die Einsätze wurden seit etwa 08:40 Uhr konsequent abgeschlossen und kehren auf ein normales Niveau zurück. Wir überwachen alle anderen Auswirkungen.

6. 19. Juli 2026 um 09:20 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Juli 2026 um 22:42 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 16. Juli 2026 um 22:42 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 16. Juli 2026 um 23:09 UTCidentified

   GitHub hat seine Statusseite aktualisiert, um die Verfügbarkeit einer eingeschränkten REST-API zu melden: https://www.githubstatus.com/incidents/gxycch3076xk

4. 17. Juli 2026 um 00:13 UTCmonitoring

   GitHub berichtet, dass sie ihren Vorfall abgemildert haben und überwachen, um Stabilität zu gewährleisten.

5. 17. Juli 2026 um 00:14 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Juli 2026 um 21:50 UTCinvestigating

   Einige Benutzer haben sich in 2FA-Anmeldeschleifen registriert, wenn sie versucht haben, auf das Render-Dashboard zuzugreifen. Wir untersuchen.

2. 15. Juli 2026 um 21:55 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 15. Juli 2026 um 22:06 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 15. Juli 2026 um 22:56 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.