Historique des pannes de Render

1. 24 octobre 2026 à 07:11 UTCidentified

   Les e-mails transactionnels pour les événements de la plateforme, y compris, mais sans s'y limiter, les confirmations de compte, les notifications de construction/déploiement de service, les réinitialisations de mot de passe, etc., ne sont actuellement pas envoyés. Nous abordons actuellement la question.

2. 24 octobre 2026 à 07:30 UTCmonitoring

   Nous avons appliqué une correction et voyons les messages livrer avec succès. Nous surveillons toute autre question.

3. 24 octobre 2026 à 07:41 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 octobre 2026 à 16:05 UTCidentified

   Nous avons identifié des performances de réseau dégradées liées à un fournisseur en amont - nous continuerons à fournir des mises à jour ici.

2. 23 octobre 2026 à 16:10 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

3. 23 octobre 2026 à 16:14 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 23 octobre 2026 à 17:34 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 20 octobre 2026 à 20:48 UTCinvestigating

   Si le clonage échoue, le déploiement échouera. Les journaux de déploiement fourniront des erreurs liées à cet échec. Réessayer un déploiement peut réussir. Nous enquêtons actuellement sur cette question.

2. 20 octobre 2026 à 21:16 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 20 octobre 2026 à 23:46 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

4. 21 octobre 2026 à 00:08 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 21 octobre 2026 à 00:29 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 octobre 2026 à 20:58 UTCidentified

   Nous avons identifié un problème avec un fournisseur de cloud en amont qui affecte les mises à jour en temps réel sur Render. Depuis environ 19:10 UTC: - Tableau de bord : les états de déploiement, les événements de service et les états de service et d'exécution des tâches peuvent ne pas être mis à jour automatiquement. Rafraîchir la page pour voir l'état actuel. - SDK appelle qu'attendre la fin d'une tâche peut échouer avec une erreur de 500 après environ 60 secondes. La tâche s'exécute et se termine normalement. Pour vérifier l'état d'une tâche, utilisez GET /v1/task-runs/{taskRunId}. Les déploiements, les services d'exploitation, les bases de données et les journaux ne sont pas affectés.

2. 15 octobre 2026 à 21:53 UTCmonitoring

   Notre fournisseur en amont a résolu le problème et les services de rendu touchés se sont rétablis. Nous continuons à surveiller.

3. 16 octobre 2026 à 01:12 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 14 octobre 2026 à 19:32 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 14 octobre 2026 à 19:45 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 14 octobre 2026 à 19:47 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

4. 14 octobre 2026 à 20:41 UTCmonitoring

   Nous arrêtons temporairement des déploiements vers des services gratuits.

5. 14 octobre 2026 à 20:55 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

6. 14 octobre 2026 à 20:57 UTCidentified

   Les constructions n'arrivent pas à recommencer dans toutes les régions, et notre équipe travaille toujours à s'attaquer à la cause profonde. Les déploiements pour des services gratuits restent interrompus. Nous partagerons une autre mise à jour dès que nous aurons plus d'informations.

7. 14 octobre 2026 à 21:43 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats. Les déploiements et les constructions pour les services fonctionnant sur des instances libres continuent d'être interrompus.

8. 14 octobre 2026 à 22:18 UTCresolved

   Cet incident a été résolu.

9. 22 octobre 2026 à 17:58 UTCpostmortem

   Résumé Le 14 octobre, 2026, entre 12:12 et 15:08 PDT \(19:12 - 22:08 UTC\), construit et déploie dans toutes les régions n'a pas commencé, a décroché, ou a été significativement retardé pendant deux périodes d'impact totalisant environ 2 heures et 20 minutes. La cause a été une migration de schéma de base de données effectuée dans le cadre d'une mise à niveau planifiée de la version de notre planificateur de travail interne qui coordonne les constructions, déploiements et autres opérations critiques de plate-forme. La migration a conduit à une charge élevée et un temps de récupération plus long que prévu de cette base de données système. Nous allons changer la façon dont nous effectuons des mises à niveau et des modifications de ce système d'une manière très disponible à l'avenir afin qu'un changement similaire ne puisse causer une panne à nouveau. Impact Il y a eu deux périodes d'impact. Pendant cette période, les services d'utilisation en direct n'ont pas été touchés, mais les constructions et les déploiements dans toutes les régions n'ont pas commencé, n'ont pas terminé ou ont été considérablement retardés. **Période 1: 12:12 - 12:40 PDT \(19:12 - 19:40 UTC\), environ 28 minutes** * Les nouvelles constructions et déploiements n'ont pas commencé. Les déploiements en cours ont échoué. * Certaines requêtes pour créer un déploiement via le tableau de bord, l'API et CLI ont retourné des erreurs \(HTTP 500\). **Recouvrement partiel: 12:40 - 13:18 PDT \(19:40 - 20:18 UTC\)** * Construire et déployer a couru, mais les déploiements ont pris environ 20 secondes pour commencer au lieu de quelques centaines de millisecondes. **Période 2: 13:18 - 15:08 PDT \(20:18 - 22:08 UTC\), environ 1 heure 50 minutes** * Les constructions et les déploiements ont été retardés, bloqués en cours \(y compris en prédéploiement\), ou échoués. A partir de 13:51 PDT, presque aucune nouvelle construction n'a pu démarrer. * Certains déploiements en file d'attente n'ont pas commencé après la récupération, et les annuler via l'API n'a eu aucun effet. Les utilisateurs devaient réessayer ces déploiements. Cause profonde Render utilise un système interne de planification des tâches pour coordonner les constructions, les déploiements et les autres opérations critiques de la plate-forme. Nous procédions à des améliorations de la façon dont il distribue le travail, et nous avons commencé une mise à niveau planifiée de ce système en production après une pratique réussie dans un environnement de test. La mise à jour comprenait une migration de schéma de base de données qui a verrouillé une grande table et conduit l'utilisation de la base de données CPU à 100%. Cette base de données stocke à la fois l'état de l'emploi de base et les données secondaires utilisées pour la recherche et le rapport. Le système ne pouvait pas lire ou écrire l'état de travail de façon fiable, donc construit et déploie arrêté ou ralenti. Les ingénieurs ont été alertés du problème rapidement et ont repris la mise à niveau. Toutefois, trois facteurs ont élargi l'impact : * Une étape de pré-upgrade pour créer un clone de base de données pour runback n'a pas pu être terminée en raison d'une erreur du fournisseur de cloud sous-jacent, de sorte qu'un runback rapide n'était pas disponible. * La migration a continué à fonctionner sur la base de données après que le client ait arrêté la mise à niveau et que la mise à niveau ait repris. Il a été retrouvé et terminé à 13:49 PDT, environ 1,5 heures après qu'il ait commencé. * Une tentative d'ajouter de la capacité à la base de données a échoué en raison d'une erreur du fournisseur de cloud sous-jacent. Calendrier Toutes les heures sont PDT au 2026-10-14 \(UTC-7\). * **12:13** - La mise à jour est commencée, y compris la migration du schéma de base de données. La charge de base de données augmente et construit et déploie cesse de démarrer. * **12:24** - Impact sur les constructions et les déploiements identifiés. L'incident s'est aggravé. * **12:33** - Ouverture de la page d'état. * **12:34** - Les ingénieurs retournent la mise à niveau et arrêtent le client effectuant la migration de schéma. * **12:37** - Le système de calendrier d'emploi se rétablit. Construit et déploie reprend, avec des temps de déploiement plus lents. Fin de la période 1. * **13:17** - Les ingénieurs redémarrent une instance malsaine du système pour rééquilibrer la charge. Les connexions et les erreurs de base de données augmentent à travers le système. Début de la période 2. * **13:37** - Free-Tier se déploie en pause pour réduire la charge. * **13:49** - Les ingénieurs trouvent la migration de schéma toujours en cours d'exécution sur la base de données et la terminent. * **14:16** - Base de données redémarrée. Une tentative d'ajouter une capacité de base de données échoue en raison d'une erreur du fournisseur de cloud sous-jacent. * **14:27** - Les autres composants du système ont redémarré. * **14:30** - Construit et déploie commence à récupérer, avec des temps de construction et de déploiement plus lents que d'habitude pendant le traitement de l'arriéré. * **15:08** - Déployer les temps de début retournent à la normale et la charge de base de données retourne aux niveaux pré-incident. Fin de la période 2. * **15:11** - Free-Tier déploie et spin-ups progressivement réactivé. * **15:18** - Règlement de l'incident. Atténuations **Complété pendant l'incident** * Réversion de la mise à jour de l'horaire de travail et modification de configuration \(12:34 PDT\). * Pased free-tier déploie et spin-ups pour réduire la charge, puis ré-activé progressivement après la récupération. * Terminé la migration de schéma qui était toujours en cours sur la base de données \(13:49 PDT\). * Redémarrage de la base de données et du système de planification des tâches pour rétablir le fonctionnement normal. * La mise à niveau a été interrompue jusqu'à ce que le processus de mise à niveau soit modifié. **En cours \(commencé pendant l'incident\)** * Cette base de données est en cours de mise à niveau afin de soutenir les zones de grande disponibilité. ** Prévue** * Mettre en oeuvre une nouvelle pratique de mise à niveau et de déploiement pour cette composante : nous mettrons en œuvre des déploiements bleu-vert pour éviter de mettre à niveau ce système sous charge à l'avenir. * Ajustez les mécanismes de stockage sous-jacents pour que le planificateur de travail soit mieux adapté à ce type de charge de travail, après avoir mis en place des déploiements bleu-vert.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 3 octobre 2026 à 19:35 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 3 octobre 2026 à 19:53 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 3 octobre 2026 à 20:13 UTCmonitoring

   Les composantes impactées se rétablissent. Nous suivons la situation.

4. 3 octobre 2026 à 20:21 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 27 septembre 2026 à 01:24 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 27 septembre 2026 à 01:36 UTCmonitoring

   Notre fournisseur en amont a commencé à se remettre. Les services en Oregon s'améliorent, et nous continuons de surveiller.

3. 27 septembre 2026 à 02:17 UTCmonitoring

   Tous les services, à l'exception des services web gratuits, se sont rétablis. Nous continuons de surveiller.

4. 27 septembre 2026 à 03:01 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 25 septembre 2026 à 18:26 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 25 septembre 2026 à 18:38 UTCresolved

   La construction et le déploiement ont échoué pour un sous-ensemble de services en Oregon. Les services utilisant une image Docker préconstruite et les sites statiques n'étaient pas touchés.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 septembre 2026 à 23:36 UTCresolved

   Vers 23h31 UTC sur 2026-09-23, les services Key Value créés avant 2024-03-05 ont été redémarrés par inadvertance en raison d'un changement de configuration à notre fin. Aucun nouveau redémarrage n'est prévu ou prévu à la suite de ce changement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 9 septembre 2026 à 21:26 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 9 septembre 2026 à 21:32 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 9 septembre 2026 à 21:34 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 9 septembre 2026 à 21:38 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 2 septembre 2026 à 17:19 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 2 septembre 2026 à 17:30 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 2 septembre 2026 à 17:40 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 août 2026 à 20:24 UTCresolved

   Certains services Web en Oregon n'étaient pas disponibles entre 19h20 et 19h30 UTC.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 août 2026 à 15:47 UTCinvestigating

   Nous enquêtons sur l'instabilité des services touchant certains services Web dans notre région de Singapour. Les clients peuvent subir des redémarrages inattendus du service ou une disponibilité intermittente. Notre équipe enquête et travaille activement pour rétablir une exploitation normale. Nous fournirons une mise à jour à mesure que de plus amples renseignements seront disponibles.

2. 31 août 2026 à 16:08 UTCinvestigating

   Nous avons observé que les déploiements sont principalement affectés par cela.

3. 31 août 2026 à 16:33 UTCinvestigating

   Le trafic entrant vers les services de Singapour est affecté. Les spin-ups de service gratuits (du ralenti) à Singapour ont été temporairement désactivés pendant que nous continuons à enquêter.

4. 31 août 2026 à 17:22 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 31 août 2026 à 18:09 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 20 août 2026 à 15:47 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 20 août 2026 à 16:12 UTCidentified

   Un problème a été identifié avec notre fournisseur en amont, Google Cloud. Services Web gratuits: Les constructions/déploiements et les spin-ups ont été temporairement désactivés pendant que nous travaillons à atténuer le problème.

3. 20 août 2026 à 17:27 UTCmonitoring

   Nous observons la reprise des constructions et des déploiements dans toutes les régions. Les constructions, les déploiements et les spin-up pour des services web gratuits ont été réactivés. Certains clients peuvent continuer à observer une latence élevée pendant que la récupération progresse. Nous continuons de surveiller.

4. 20 août 2026 à 17:45 UTCmonitoring

   Nous avons observé une reprise complète. Nous continuons de surveiller toute autre question.

5. 20 août 2026 à 19:40 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 27 juillet 2026 à 14:43 UTCinvestigating

   Les demandes à travers le tableau de bord peuvent être plus lentes que d'habitude. Nous enquêtons actuellement sur la question.

2. 27 juillet 2026 à 17:59 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 27 juillet 2026 à 18:27 UTCinvestigating

   L'API REST connaît également des performances dégradées. Par conséquent, les demandes peuvent faire l'objet de délais et vous devrez peut-être réessayer votre demande. Nous continuons d'enquêter.

4. 27 juillet 2026 à 20:18 UTCmonitoring

   Nous avons mis en place un correctif et suivons les résultats. Les raisons de l'échec du déploiement seront temporairement indisponibles. Des événements d'échec de déploiement seront encore générés. Nous fournirons une mise à jour une fois que les raisons de l'échec du déploiement seront réactivées.

5. 27 juillet 2026 à 23:58 UTCmonitoring

   Aucun autre problème n'a été observé depuis nos corrections. Le tableau de bord et l'API REST demeurent pleinement opérationnels. Les raisons de l'échec du déploiement sont toujours désactivées. Nous mettrons à jour cet incident une fois qu'il sera réactivé. Aucune autre mise à jour n'est prévue pour aujourd'hui (2026-07-27, UTC-7).

6. 28 juillet 2026 à 19:35 UTCresolved

   Nous n'avons pas observé d'autres problèmes et les raisons d'échec de déploiement ont été réactivées.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 juillet 2026 à 11:16 UTCinvestigating

   Nous enquêtons sur un problème d'infrastructure touchant les services hébergés dans notre région de l'Oregon. Certains services peuvent être inaccessibles ou faire l'objet d'un échec. Notre équipe d'ingénieurs travaille activement à identifier la cause et à rétablir le fonctionnement normal.

2. 24 juillet 2026 à 11:27 UTCmonitoring

   Nous avons observé la reprise dans tous les services et nous suivons maintenant la situation.

3. 24 juillet 2026 à 11:44 UTCmonitoring

   Nous croyons que le problème a été causé par un fournisseur en amont. Nous continuons de surveiller la situation.

4. 24 juillet 2026 à 13:30 UTCresolved

   Cet incident a maintenant été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 20 juillet 2026 à 00:41 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 20 juillet 2026 à 00:55 UTCidentified

   GitHub continue de signaler une panne, https://www.githubstatus.com. Cela provoque des défaillances d'authentification lors du déploiement à partir d'un dépôt GitHub.

3. 20 juillet 2026 à 01:54 UTCmonitoring

   Nous assistons maintenant à une reprise de notre taux d'échec de construction. Nous continuons de suivre la question.

4. 20 juillet 2026 à 02:11 UTCresolved

   Les taux d'échec des constructions se sont rétablis. Résolution.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 19 juillet 2026 à 03:44 UTCinvestigating

   Nous avons reçu un nombre élevé de rapports sur des défaillances de clones git qui ont entraîné une erreur de 403, avortant le déploiement. Nous enquêtons.

2. 19 juillet 2026 à 03:55 UTCidentified

   Les services qui ne sont pas déployés sont ceux qui sont déployés à Francfort. Les services de fonctionnement ne sont pas affectés, seul le processus de déploiement échoue. Nous travaillons toujours à déterminer la cause de cette erreur pour ces services.

3. 19 juillet 2026 à 05:57 UTCidentified

   Les utilisateurs avec des services hébergés à Francfort qui comptent sur les dépôts GitHub pour les déploiements continuent à voir 403 erreurs dans leurs journaux, ce qui cause l'échec du déploiement. Nous continuons de travailler sur cette question au sein de nos propres systèmes et nous nous sommes adressés à GitHub.

4. 19 juillet 2026 à 08:29 UTCidentified

   Nous continuons de travailler à atténuer cette question, tout en travaillant avec GitHub pour résoudre ces défaillances de déploiement.

5. 19 juillet 2026 à 09:10 UTCmonitoring

   Les déploiements se terminent régulièrement depuis environ 08h40 et reviennent à des niveaux normaux. Nous surveillons tout autre impact.

6. 19 juillet 2026 à 09:20 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 juillet 2026 à 22:42 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 16 juillet 2026 à 22:42 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 16 juillet 2026 à 23:09 UTCidentified

   GitHub a mis à jour sa page d'état pour signaler la dégradation de la disponibilité de l'API REST: https://www.githubstatus.com/incidents/gxycch3076xk

4. 17 juillet 2026 à 00:13 UTCmonitoring

   GitHub signale qu'ils ont atténué leur incident et qu'ils surveillent la stabilité.

5. 17 juillet 2026 à 00:14 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 juillet 2026 à 21:50 UTCinvestigating

   Certains utilisateurs inscrits dans 2FA déclarent des boucles de connexion lors d'une tentative d'accès au tableau de bord Render. Nous enquêtons.

2. 15 juillet 2026 à 21:55 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 15 juillet 2026 à 22:06 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 15 juillet 2026 à 22:56 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.