Historique des pannes de Uipath

1. 27 octobre 2026 à 16:39 UTCresolved

   Le 27 octobre 2026, entre 14h35 et 16h08 UTC, Document Understanding en Europe a connu une panne partielle affectant l'extraction générative, la classification générative et l'autovalidation. La cause principale était un problème de connectivité avec un fournisseur de stockage tiers. La connectivité a été rétablie, et nous avons confirmé que l'extraction et la classification fonctionnent normalement depuis 16:08 UTC.

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

1. 26 octobre 2026 à 14:04 UTCidentified

   Nous enquêtons actuellement sur un problème qui a une incidence sur la disponibilité des informations et des services d'automatisation. Notre équipe évalue activement la situation afin d'identifier la cause sous-jacente et de déterminer les étapes nécessaires pour rétablir des opérations normales. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 26 octobre 2026 à 15:35 UTCidentified

   Le problème des opérations d'automatisation a été résolu. Nous attendons actuellement que la question du service Insights soit atténuée. D'autres mises à jour seront communiquées dès qu'elles seront disponibles.

3. 26 octobre 2026 à 17:09 UTCidentified

   Service Insights à Singapour, au Japon, en Suisse, au Canada, en Inde, au Royaume-Uni, en Europe, aux États-Unis, aux Émirats arabes unis, en Corée du Sud et en Australie

4. 26 octobre 2026 à 18:27 UTCresolved

   Le problème a été résolu et tous les services fonctionnent maintenant normalement.

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

1. 27 octobre 2026 à 10:13 UTCresolved

   Le 26 octobre 2026, entre 10h20 et 17h30 UTC, Automation Cloud Robots (VM) a connu une panne partielle affectant le fonctionnement de la machine. Pendant cette fenêtre, des actions telles que le démarrage, l'arrêt ou la fourniture de machines VM peuvent ne pas avoir été effectuées, et les travaux prévus sur ces machines peuvent avoir été retardés ou endommagés. La cause était une erreur de configuration des autorisations sur un sous-ensemble des ressources d'infrastructure sous-jacentes. Notre équipe a identifié le problème, corrigé la configuration et confirmé que les opérations de la machine fonctionnent normalement depuis 17:30 UTC. Nous examinons la façon dont la mauvaise configuration a été introduite et ajoutons des contrôles pour éviter une récurrence. Aucune action n'est requise de votre côté. Si vous voyez toujours des travaux échoués ou bloqués à partir de cette fenêtre, veuillez les essayer à nouveau et contacter le support si le problème persiste.

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

1. 23 octobre 2026 à 21:35 UTCresolved

   Entre 20h42 et 21h19 UTC le 23 octobre, certains clients d'Orchestre en Europe ont vu des réponses lentes et des erreurs intermittentes. Cela incluait les appels de robots pour obtenir des actifs, traiter les éléments de file d'attente et rapporter l'état de travail. Certains emplois sans surveillance ont peut-être échoué pendant cette période. La cause a été une augmentation soudaine de la charge qui a atteint les limites de ressources de la base de données. Nous avons ajouté une capacité de base de données, et la performance est revenue à la normale depuis 21:19 UTC. Les clients dont les travaux ont échoué dans cette fenêtre peuvent avoir besoin de les redémarrer.

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

1. 22 octobre 2026 à 12:59 UTCinvestigating

   Nous avons identifié un problème affectant IXP pour les clients hébergés dans la région de l'Australie. Depuis 10h24 UTC, les demandes qui utilisent le modèle Gemini 2.5 Flash échouent dans la région. Les autres modèles ne sont pas affectés. Les données des clients ne sont traitées qu'en Australie. Nous travaillons avec Google pour restaurer le service

2. 22 octobre 2026 à 14:19 UTCmonitoring

   Un correctif a été déployé et le service se rétablit. Nous surveillons le système pour assurer une récupération complète. D'autres mises à jour seront bientôt diffusées

3. 22 octobre 2026 à 14:33 UTCinvestigating

   Après la récupération initiale, le service s'est à nouveau dégradé. Nous enquêtons et travaillons à une résolution. Nous fournirons d'autres mises à jour à mesure qu'elles seront disponibles.

4. 22 octobre 2026 à 15:42 UTCinvestigating

   Nous avons contacté Google Support, et ils ont commencé à enquêter sur leur fin. Nous continuerons de surveiller et de partager les mises à jour.

5. 22 octobre 2026 à 17:56 UTCmonitoring

   Nous observons des améliorations sur Gemini 2.5 Flash trafic. Nous surveillons une solution possible de Google.

6. 22 octobre 2026 à 21:02 UTCresolved

   Le problème est résolu à partir de Google.

7. 26 octobre 2026 à 03:20 UTCpostmortem

   ## Impact client Entre le 22 octobre 2026 à 10h24 UTC et le 22 octobre 2026 à 18h04 UTC, les demandes de traitement de documents ayant utilisé Gemini 2.5 Flash dans la région de l'Australie ont échoué avec des erreurs de capacité. L'impact a duré environ 7 heures et 40 minutes. Un sous-ensemble de clients utilisant des flux de travail d'extraction de documents dans cette région ont été touchés. Lors d'une tentative de repli temporaire dans la région, certaines demandes d'extraction ont été récupérées brièvement, mais l'attribution de mots et le texte de page généré ont été dégradés jusqu'à ce que le repli ait également commencé à échouer. Cause profonde La cause principale était une perturbation du réseau régional côté fournisseur pendant la maintenance simultanée. Cela a entraîné un étranglement de la bande passante sévère dans l'environnement de serveur de modèles du fournisseur, ce qui a empêché les systèmes d'arrière-plan de charger les données du modèle nécessaires pour répondre de façon fiable aux demandes Gemini 2.5 Flash et Gemini 3.5 Flash dans la région touchée. Détection Le problème a été détecté au moyen d'alertes automatisées qui ont identifié des erreurs de limitation de vitesse sur Gemini 2.5 Flash dans la région de l'Australie. Notre équipe d'ingénieurs a confirmé par télémétrie que les demandes en cause manquaient constamment et a commencé à coordonner une réponse. Réponse À 13h40 UTC, nous avons acheminé le trafic Gemini 2.5 Flash vers Gemini 3.5 Flash dans la même région pour préserver la résidence des données. La télémétrie initiale n'a révélé aucune erreur de capacité après ce changement, mais à 14 h 10 UTC, Gemini 3.5 Flash était également une erreur de capacité de retour, de sorte que le recul n'était plus viable. À 14 h 05 UTC, nous avons ajusté les chemins de traitement des documents connexes afin que l'attribution et la génération de pages-texte utilisent le même recul dans la région; cet ajustement a été effectué vers 14 h 09 UTC. Après que le retour a également échoué, nous avons retourné le changement de routage, et à 16h28 le trafic UTC était de retour sur le chemin attendu Gemini 2.5 Flash. À 17h38 UTC, la télémétrie a montré une amélioration des taux de succès Gemini 2.5 Flash. À partir de 18h04 UTC, aucune autre erreur de capacité n'a été observée et les demandes subséquentes ont été satisfaites. Suivi 1. Achever l ' évaluation des capacités du modèle réservé pour la région touchée en utilisant les schémas de circulation observés 2. Évaluer le comportement de réessayer et de désamorcer dans les clients de traitement de documents afin de réduire l'amplification de réessayer pendant les défaillances de capacité côté fournisseur.

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

1. 15 octobre 2026 à 12:27 UTCinvestigating

   Depuis environ 11h17 UTC, les clients de plusieurs régions ont eu des problèmes avec UiPath Agents et Solutions Management. De nouveaux emplois peuvent rester en attente, et les agents exécutants peuvent subir des retards lors du traitement des escalades ou attendre les résultats de l'outil. Nous enquêtons sur la question et travaillons à une résolution.

2. 15 octobre 2026 à 13:04 UTCmonitoring

   La question a été atténuée. Nous surveillons les services touchés dans toutes les régions afin d'assurer la stabilité et de confirmer que les départs d'emplois et les déploiements de solutions fonctionnent normalement.

3. 15 octobre 2026 à 13:22 UTCresolved

   Cet incident a été résolu. Entre 11h15 et 12h45 UTC le 15 octobre, un problème de configuration interne a empêché certains événements de se produire entre les services UiPath dans plusieurs régions. La question a été résolue en faisant reculer le changement, et de nouvelles activités sont traitées normalement. Certains travaux entrepris ou en cours durant cette fenêtre peuvent nécessiter une attention particulière : - Agents : Les agents qui attendent les tâches du Centre Action ou les résultats de l'outil d'automatisation peuvent rester bloqués. Les emplois commencés à partir de Orchestrator peuvent également apparaître bloqués ou temps mort. - Maestro: Les processus en attente des tâches utilisateur peuvent ne pas avoir repris après l'achèvement des tâches. - Apps : Les statuts d'éléments de file d'attente peuvent être dépassés, et les actions déclenchées par l'achèvement d'éléments de file d'attente peuvent ne pas avoir été exécutées. - Pilote automatique pour tous : les conversations en attente de résultats d'automatisation peuvent rester bloquées. - Compréhension des documents et contexte Base : Les automatismes et les agents en attente d'extraction, de validation ou d'indexation peuvent rester suspendus. - Service d'intégration : Les événements de connexion n'ont peut-être pas déclenché les processus ou notifications attendus. - Solutions et Studio Web: Solution installe, désinstalle, publie, déploie et validations initiées pendant cette fenêtre peut avoir échoué ou chronométré. La reprise de ces opérations peut résoudre le problème. Nous nous excusons pour cette perturbation et vous remercions de votre patience.

4. 21 octobre 2026 à 06:47 UTCpostmortem

   **Effet client** Le 15 octobre 2026, de 11h15 à 12h50 UTC (environ 1 heure et 35 minutes), certains événements échangés entre les services cloud d'UiPath n'ont pas été livrés. Les clients de toutes les régions du cloud commercial ont été touchés. Pendant cette fenêtre: - Les nouveaux agents pourraient rester en attente. Les agents exécutants qui attendent le résultat d'un outil, une escalade humaine, une extraction de documents ou une mise à la terre de contexte pourraient ne pas reprendre. - Agents de conversation et Autopilot for Everyone conversations qui ont commencé une automatisation pourrait ne pas avoir reçu son résultat. - Les instances de processus Maestro en attente d'une tâche utilisateur n'ont peut-être pas avancé une fois la tâche terminée, et les processus déclenchés par les événements de connecteur du service d'intégration n'ont peut-être pas commencé. - Les applications montrant ou réagissant à l'état de la file d'attente pourraient afficher des informations obsolètes. - Solution installe, désinstalle, publie et déploie peut échouer ou s'arrêter. - Certains changements d'utilisateur, de groupe et de dossier effectués dans la fenêtre n'auraient pas pu se propager à tous les services. Le travail commencé après 12h50 UTC n'a pas été affecté. L'exécution de tâches robotisées, les files d'attente et les déclencheurs gérés à l'intérieur de Orchestrator continuaient de fonctionner normalement. ** Cause de la mort** Nous avons déplacé la prestation de la configuration de service interne vers un nouveau mécanisme, un changement destiné à n'avoir aucun effet sur les clients. Lorsque ce changement a été appliqué au service de livraison d'événements, la configuration qu'il a produite manquait une valeur requise. Sans cela, le service a traité plusieurs intégrations de produits comme étant désactivées et a cessé silencieusement de livrer leurs événements. Comme le changement touchait toutes les régions de production en même temps, chaque région était touchée. **Détection** Le problème a été détecté à 11h51 UTC, environ 35 minutes après le début de l'impact, lorsque la surveillance a été alertée sur les emplois d'agent restant en attente. Des rapports de déploiements de solutions ont été suivis, et un incident a été déclaré à 12h12 UTC. **Réponse** Après la première détection à 11h51 UTC, le changement de configuration a été identifié et un retour en arrière a été amorcé à 12h00 UTC. Un retour initial à 12:14 UTC n'a pas complètement rétabli la livraison. L'équipe a ensuite arrêté le nouveau processus de livraison de configuration et a restauré la configuration précédente. La livraison de l'événement a commencé à se rétablir à 12h40 UTC, et le rétablissement complet dans toutes les régions a été confirmé à 12h50 UTC. Dans la mesure du possible, nous avons rejoué des événements manqués afin que le travail affecté puisse continuer. **Suivi** 1. Le nouveau processus de livraison de configuration a été interrompu pour le service affecté et restera interrompu jusqu'à ce que la configuration soit générée correctement. 2. Valider la configuration produite par le nouveau mécanisme de livraison pour les valeurs requises avant qu'elle ne soit appliquée à tout environnement. 3. Mettre en œuvre progressivement les modifications apportées à la configuration d ' une région à l ' autre plutôt qu ' à toutes les régions en même temps. 4. Améliorer notre surveillance pour détecter en quelques minutes quand les événements cessent d'être livrés à une intégration de produit qui les reçoit normalement. 5. Améliorer notre capacité de récupérer et de refaire les événements manqués pendant une perturbation.

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

1. 15 octobre 2026 à 12:03 UTCresolved

   Certains clients de la région des États-Unis ont connu des retards dans l'ingestion de logs de robots, avec une augmentation de l'activité observée entre 11h20 et 11h45 UTC. Le problème a été résolu et l'ingestion de logs est revenue à la normale. Merci de votre patience.

2. 22 octobre 2026 à 10:13 UTCpostmortem

   ## Impact client Entre environ le 15 octobre 2026 à 23h20 UTC et environ le 15 octobre 2026 à 23h45 UTC, certains clients de la région de l'Est des États-Unis ont connu des retards dans l'ingestion de logs robots dans l'orchestreur UiPath. Les registres des robots n'étaient pas à jour pendant la période touchée. L'impact a duré environ 20 minutes. Cause profonde Au cours de l'incident, 2 des 13 instances de service qui manipulaient l'ingestion de log robot ont été observées et n'ont pas été reliées au service d'ingestion de l'événement. Seules les demandes au service d'ingestion de l'événement ont échoué, et seulement dans ces deux cas. Cela a fait que certaines demandes d'ingestion de log robot ne se sont pas terminées avec succès, ce qui a retardé les données de log pour les clients touchés. La cause profonde de la perte de connectivité au service d'ingestion n'a pas été déterminée au cours de l'incident. L'équipe s'est engagée à examiner les registres des cas touchés après l'incident pour déterminer la cause sous-jacente. Nous croyons qu'il s'agit d'un problème d'infrastructure non signalé de la part de notre fournisseur de cloud. Détection Le problème a été détecté par une alerte automatisée vers 23h33 UTC le 15 octobre 2026 et confirmé par télémétrie montrant des exceptions aux deux cas de service touchés. Réponse Après la détection, la télémétrie a confirmé que seulement deux instances de service généraient des exceptions. Les intervenants ont retiré ces deux instances malsaines du service, et les instances de remplacement ont commencé automatiquement. Dans environ 20 minutes de la première alerte — vers 23h53 UTC — la télémétrie indiquait que des contrôles de récupération et de surveillance synthétique étaient effectués. Un redémarrage plus large de toutes les instances de service a été envisagé mais n'a pas été effectué, car l'équipe a déterminé qu'il ne devrait pas procéder sans d'abord comprendre la cause fondamentale. Suivi 1. Un examen post-incident des journaux des instances de service touchées a révélé que le problème était lié à l'infrastructure, et nous suivons avec le fournisseur d'infrastructure cloud pour plus de détails. 2. Une mise à jour sera publiée si l'enquête donne lieu à d'autres constatations.

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

1. 14 octobre 2026 à 07:26 UTCmonitoring

   À partir de 6h50 UTC, nous avons connu une panne mondiale qui a affecté le chargement des applications et des applications codées dans toutes les régions, sauf en Inde et au Royaume-Uni. Les pannes ont été résolues et les services sont pleinement opérationnels. Impact: Aucun impact utilisateur en cours.

2. 14 octobre 2026 à 07:43 UTCresolved

   À partir de 6h50 UTC, nous avons connu une panne mondiale qui a affecté le chargement des applications et des applications codées dans toutes les régions, sauf en Inde et au Royaume-Uni. Les pannes ont été résolues et les services sont pleinement opérationnels. Impact: Aucun impact utilisateur en cours.

3. 23 octobre 2026 à 12:08 UTCpostmortem

   ## Impact client Entre 06h38 UTC et 07h21 UTC le 14 octobre 2026, une partie des demandes à UiPath Apps, des applications codées et des solutions qui en dépendent ont échoué dans onze régions : Europe, États-Unis, Communauté, Japon, Singapour, Australie, Canada, Corée du Sud, Suisse, Émirats arabes unis et l'environnement américain retardé. Les régions de l'Inde et du Royaume-Uni n'ont pas été touchées. Environ 2 % des demandes ont échoué dans l'ensemble, entre 0,6 et 5 % selon la région. Les utilisateurs touchés ont vu que les applications ne se chargent pas, demandent des erreurs de serveur ou des réponses lentes. Dans les régions où les modules de service ont dû être redémarrés, les applications étaient inaccessibles pendant environ huit minutes. Les temps de réponse étaient de retour à la normale dans chaque région à 07:40 UTC. La plupart des utilisateurs d'applications déjà publiées ont remarqué peu ou rien. Les définitions de l'application sont mises en cache dans le navigateur pendant jusqu'à 24 heures, les données de l'application proviennent de Data Service et Orchestrator plutôt que de cette base de données, et le service est maintenu en utilisant les connexions de la base de données qu'il détenait déjà. Les requêtes qui ont échoué étaient celles qui avaient besoin d'une nouvelle connexion de base de données : ouverture du concepteur ou de la liste des applications, chargement d'une application non encore mise en cache, téléchargement de documents et d'images stockées dans les applications, enregistrement ou publication. Cause profonde À 6h38 UTC, alors que l'accès à la base de données était en cours de mise en place pour un nouveau déploiement régional, le mot de passe de l'utilisateur de la base de données utilisé par le service Apps a été modifié. Cet utilisateur est partagé par les groupes de la base de données de production de toutes les régions touchées, de sorte que le changement appliqué à toutes ces régions à la fois. Les services en cours d'exécution détiennent toujours le mot de passe précédent et ne peuvent plus ouvrir de nouvelles connexions de base de données. Les régions de l'Inde et du Royaume-Uni n'utilisent pas ce titre et n'ont pas été touchées. Le changement visait à créer un utilisateur de base de données distinct pour la nouvelle région. Au lieu de cela, le mot de passe de l'utilisateur existant que toutes les régions partagent a été modifié. Notre processus de changement pour les justificatifs de base de données n'a pas clairement séparé la création d'un nouveau justificatif de la modification d'un justificatif existant, et il n'a pas fallu vérifier combien de grappes et de régions un changement de justificatif affecterait. Combiné avec un seul utilisateur de base de données partagé entre les régions, cela a permis un changement destiné à une région pour causer une panne multi-régions. Détection Notre surveillance interne a soulevé la première alerte à 06h41 UTC, trois minutes après les premières défaillances, et alertes pour chaque région touchée suivie de 06h46 UTC. À 6 h 50 UTC, l'ingénieur sur appel a confirmé que chaque groupe de production était refusé par sa base de données et a commencé le processus d'incident. Réponse À 07h05 UTC, le mot de passe précédent a été restauré et les défaillances d'authentification ont cessé partout. La plupart des régions se reconnectent automatiquement. Dans les régions qui ne l'ont pas fait, les modules de service ont été redémarrés ou redéployés : les États-Unis ont été retardés à 07h21 UTC et la Suisse à 07h30 UTC. Les défaillances de la demande ont cessé à 07:21 UTC, les temps de réponse ont été de retour au niveau de référence à 07:40 UTC, et nous avons continué à surveiller jusqu'à ce que l'incident soit résolu à 07:43 UTC. Suivi Pour éviter que cela ne se reproduise, nous sommes : - Introduire une procédure définie pour la création et la rotation des justificatifs de base de données, avec un examen préalable au changement qui indique quels groupes et régions partagent les justificatifs, et un déploiement échelonné qui est vérifié dans une région avant qu'il ne soit appliqué plus largement. - Se déplacer vers des utilisateurs de base de données distincts, les moins privilégiés pour chaque région, de sorte qu'un changement dans une région ne puisse affecter une autre. - Déclarer automatiquement un incident et rechercher les propriétaires de bases de données lorsque la même erreur de base de données est détectée dans plusieurs régions à la fois, au lieu de compter sur une escalade manuelle des alertes régionales individuelles. - Permettre aux services de récupérer les identifiants de base de données mis à jour sans redémarrer, et de se reconnecter plus rapidement après un échec d'authentification.

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

1. 13 octobre 2026 à 14:03 UTCinvestigating

   Nous enquêtons actuellement sur une panne affectant les services UiPath Cloud dans plusieurs régions. Les utilisateurs sont incapables d'accéder aux services hébergés dans les régions touchées. Prochaine mise à jour: Des informations supplémentaires seront communiquées dès qu'elles seront disponibles.

2. 13 octobre 2026 à 14:37 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 13 octobre 2026 à 14:42 UTCinvestigating

   Un correctif a été mis en place et nous suivons les résultats. La question se limitait à la compréhension des documents, à la vision de l'ordinateur, au proxy sémantique, au studi pilote automatique, à l'IXP. Nous partagerons une autre mise à jour une fois que les services auront complètement récupéré.

4. 13 octobre 2026 à 15:10 UTCinvestigating

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

5. 13 octobre 2026 à 15:19 UTCresolved

   Cet incident a été résolu à la suite du renouvellement du certificat SSL expiré qui a affecté plusieurs services dépendants de ML, dont IXP, Document Understanding, Computer Vision, Semantic Proxy et Autopilot pour les développeurs. Le rétablissement des services a progressé dans les régions touchées, et des alertes automatisées ont été configurées afin d'aider à détecter l'expiration du certificat à l'avance et d'éviter des perturbations semblables à l'avenir. Merci de votre patience et de votre compréhension.

6. 26 octobre 2026 à 03:17 UTCpostmortem

   Impact client Entre 13 h 37 et 14 h 40 UTC le 13 octobre 2026, les clients de plusieurs régions n'ont pas pu utiliser les documents non structurés du PSI, l'exploitation minière des communications du PSI et la compréhension des documents. Les fonctions Computer Vision et Autopilot for Developers qui dépendent des mêmes services d'apprentissage automatique ont également échoué. Les clients touchés ont vu des demandes échouer avec les réponses "500 Internal Server Error" ou le délai de sortie, les projets IXP qui ne s'ouvriraient pas, et les activités Computer Vision qui échouent dans l'automatisation. Le service a été interrompu pendant environ 1 heure. Aucune donnée client n'a été perdue. La cause profonde L'incident a été causé par un certificat de sécurité expiré utilisé pour établir des connexions sécurisées à ces services. Le certificat est renouvelé par un processus automatisé. Ce processus ne s'exécutait plus avec succès et les échecs n'ont pas soulevé d'alerte, de sorte que le certificat n'a pas été remplacé avant son expiration. Les connexions sécurisées aux services concernés ont été rejetées à partir de 13h37 UTC. Détection La surveillance automatisée a commencé à alerter les erreurs et la circulation manquante à 13h40 UTC, et l'incident a été déclaré à 13h54 UTC. Le certificat expiré a été identifié à 14h00 UTC, et la première mise à jour de la page d'état a été affichée à 14h03 UTC. Aucune alerte n'a mis en garde contre l'expiration du certificat, et les échecs répétés du renouvellement automatisé n'ont pas été signalés à l'équipe propriétaire, de sorte que le problème n'a été détecté que lorsque les clients ont été touchés. Réponse À 14 h 06 UTC, l'équipe a confirmé que le certificat avait expiré parce que le renouvellement automatisé avait échoué. À 14 h 18 UTC, un nouveau titre a été délivré pour le processus de renouvellement. Le renouvellement a débuté manuellement à 14:19 UTC et s'est terminé à 14:33 UTC, et à 14:37 UTC tous les critères d'évaluation orientés vers le client avaient été vérifiés pour signifier le certificat renouvelé. La circulation est revenue à des niveaux normaux d'environ 14h40 UTC. Après une période de surveillance, l'incident a été résolu à 15:19 UTC. Suivi Pour aider à prévenir des incidents semblables à l'avenir, nous apportons les améliorations suivantes : - Alertez bien avant l'expiration de ces certificats. - Prévenez l'équipe propriétaire quand le renouvellement automatisé échoue. - Ajouter des vérifications de cette alerte dès que les connexions sécurisées à ces services échouent. - Renforcer la propriété du processus de renouvellement du certificat et les titres de compétence sur lesquels il repose.

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

1. 13 octobre 2026 à 10:32 UTCinvestigating

   Nous enquêtons sur la question où les registres d'exécution des robots ne se présentent pas dans Orchestrator. nous travaillons à déterminer la portée et la cause profonde.

2. 13 octobre 2026 à 10:57 UTCresolved

   Cette question a été résolue. Les journaux d'exécution des robots se synchronisent et sont à nouveau visibles dans Orchestrator pour le Japon Orchestrator. Merci de votre patience.

3. 22 octobre 2026 à 13:25 UTCpostmortem

   ## Impact client Entre environ 07:00 UTC le 9 Oct 2026 et 10:45 UTC le 13 Oct 2026, environ 6% des entrées de journaux robots pour les clients de la région du Japon n'apparaissent pas dans Orchestrator. L'exécution des tâches et toutes les autres fonctionnalités de l'Orchestre n'ont pas été affectées. Les inscriptions manquantes sont devenues visibles dans Orchestrator après que le numéro a été corrigé. Cause profonde Les journaux de robots sont placés sur une file d'attente divisée en 32 partitions, et un service d'ingestion lit chaque partition et stocke les journaux pour Orchestrator. Le 9 octobre, le service d'ingestion dans la région du Japon a cessé de lire à partir de 2 des 32 cloisons sans signaler une erreur. Les registres de ces partitions étaient conservés dans la file d'attente mais non stockés, de sorte qu'ils n'apparaissaient pas dans Orchestrator. Notre surveillance a vérifié le service dans son ensemble, pas chaque partition, donc le problème n'a pas été détecté automatiquement. Détection Le problème a été détecté dans les rapports des clients. Nous avons déclaré un incident à 10 h 13 UTC le 13 octobre et affiché un avis d'état à 10 h 32 UTC. Réponse Nous avons redémarré le service d'ingestion à environ 10h41 UTC, et il a repris la lecture de toutes les partitions. Les registres tenus dans la file d'attente ont ensuite été traités et sont devenus visibles dans Orchestrator. L'incident a été résolu à 10h57 UTC. Suivi * Nous ajoutons une surveillance qui nous avertit quand une partition cesse d'être lue, donc ce genre de problème est détecté en quelques minutes.

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

1. 7 octobre 2026 à 21:34 UTCinvestigating

   Nous enquêtons sur les rapports d'une panne ayant un impact sur la création de tâches HITL pour Maestro aux États-Unis. Impact : Les utilisateurs peuvent ne pas être en mesure de créer des tâches HITL. Prochaine mise à jour: Nos équipes s'efforcent de comprendre la cause et la portée et partageront les mises à jour disponibles.

2. 8 octobre 2026 à 01:30 UTCidentified

   Nous avons identifié la cause d'une panne ayant une incidence sur la création de tâches HITL pour Maestro aux États-Unis et nous travaillons à atténuer le problème. Impact : Les utilisateurs peuvent ne pas être en mesure de créer des tâches HITL. Prochaine mise à jour : Nos équipes s'efforcent d'atténuer le problème et partageront les mises à jour disponibles.

3. 8 octobre 2026 à 03:28 UTCmonitoring

   Nous sommes en train de déployer fix pour une panne impactant la création de tâches HITL pour Maestros avec HITL tâche SLA minuters configurés aux États-Unis et travaillent à atténuer le problème. Impact: Les utilisateurs peuvent ne pas être en mesure de créer des tâches HITL dans Maestros avec des minuteurs HITL Task SLA configurés. Prochaine mise à jour : Nos équipes s'efforcent d'atténuer le problème et partageront les mises à jour disponibles.

4. 8 octobre 2026 à 04:29 UTCresolved

   La correction pour le problème impactant la création de tâches HITL pour Maestro avec les minuteurs SLA de tâches HITL configurés aux États-Unis a été complètement déployée. La création de tâches HITL est revenue à la normale.

5. 26 octobre 2026 à 03:16 UTCpostmortem

   ## Impact client Le 2026-10-05 entre 9h30 UTC - 2026-10-07 3h30 Les clients UTC, Maestro BPMN et Case utilisant des nœuds HITL avec un minuteur de tâches configuré ont vu des défaillances de leurs instances de débogage et de production au stade HITL, avec 4xx . Une trentaine d'exemples de ce type ont été identifiés à travers les États-Unis et l'Europe, qui ont été bloqués sans solution de rechange. Cause profonde La configuration d'une tâche SLA nécessite un objet comprenant les critères de début et de fin, le minuteur de la tâche SLA et le résultat de la rupture SLA. Les clients configurent cela sur le concepteur Maestro sur le nœud HITL. Le résultat a été par erreur maintenu non obligatoire sur la surface de conception, même si une configuration SLA sans résultat n'est pas persistante et n'a pas de sens commercial. L'équipe de backend d'Action Center avait ajouté une validation pour lancer une mauvaise requête (400) en cas d'un objet SLA non nul avec un résultat manquant. Cela a fini par avoir un impact sur les clients qui avaient ajouté les critères Start/End sur le nœud, mais pas configuré un résultat. Les instances qui couraient auparavant ont échoué avec 400, et n'ont pas pu reprendre Détection Un client a signalé la question à Maestro Engineering PME, qui l'a soulevée en interne avec l'équipe. L'équipe de Maestro a enquêté sur cet échec et a observé un nombre croissant d'échecs pour l'USI, et quelques autres locataires par l'intermédiaire de journaux, les conduisant à engager l'équipe d'Action Center. Réponse L'équipe de Maestro a reçu le rapport du client par courrier électronique, et ils ont fait une enquête initiale et identifié une régression potentielle, après quoi, le centre d'action PME a été engagé, la question reproduite sur les environnements inférieurs, un retour de la fonctionnalité appliquée et testé, et déployé dans toutes les régions touchées. Elle a été résolue avec tous les cas ayant fait l'objet d'une reprise interne. Suivi 1. Ajouter la validation de ce scénario sur toutes les surfaces de base de codes transversaux pour assurer l'examen humain 2. Ajouter les tests de surveillance et d'intégration requis en place pour détecter ce problème plus rapidement

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

1. 7 octobre 2026 à 17:37 UTCinvestigating

   Nous enquêtons sur des rapports de lenteur intermittente et d'erreurs affectant un sous-ensemble d'organisations de la région d'Automation Cloud aux États-Unis. Les utilisateurs touchés peuvent voir les pages de l'interface utilisateur Orchestrator ne pas charger (par exemple, la page Jobs renvoyant "Une erreur s'est produite"), et les opérations de robots telles que les transactions en file d'attente et les démarrages de session peuvent se terminer par intermittence. Nous fournirons une mise à jour dès que de plus amples renseignements seront disponibles.

2. 7 octobre 2026 à 18:13 UTCmonitoring

   Nous avons appliqué une augmentation de capacité à l'infrastructure de base de données touchée dans la région de l'Est des États-Unis et les taux d'erreur et de latence sont revenus à des niveaux normaux. Nous fournirons une mise à jour dès que de plus amples renseignements seront disponibles.

3. 7 octobre 2026 à 19:06 UTCresolved

   Nous avons le problème dans la région est des États-Unis et les taux d'erreur et de latence sont revenus à des niveaux normaux.

4. 14 octobre 2026 à 11:42 UTCpostmortem

   ## Impact client Entre 13h00 UTC et 18h15 UTC le 7 octobre 2026, les clients de la région américaine ont connu des erreurs intermittentes et des réponses lentes dans Orchestrator. Les utilisateurs touchés peuvent avoir vu que les pages Orchestrator ne se chargent pas, par exemple la page Jobs renvoyant une erreur, et les opérations de robot telles que les transactions en file d'attente et les démarrages de session peuvent avoir été chronométrés par intermittence. D'autres services UiPath qui dépendent de Orchestrator peuvent aussi avoir vu des réponses ou des erreurs plus lentes pendant cette période. Cause profonde Plusieurs opérations souvent utilisées par les Orchestrator se sont chacune appuyées sur une ressource partagée de courte durée à l'intérieur de la base de données, y compris la vérification de l'état de routine de chaque robot en cours d'exécution. Au fur et à mesure que le volume d'activité des robots concomitants dans cette région augmentait, les demandes ont commencé à faire la queue pour avoir accès à cette ressource partagée au lieu de terminer leur travail. L'effet a été sélectif plutôt qu'un ralentissement général : les opérations qui ont utilisé cette ressource ont été retardées, tandis que d'autres ont continué à fonctionner normalement. Comme le processeur de la base de données, l'utilisation de la mémoire et du stockage sont restés dans les intervalles normaux, la surveillance régulière de la capacité n'a pas révélé de problème. Détection Notre surveillance automatisée a détecté la dégradation dans les environ 35 minutes suivant le début de l'impact client, et nos ingénieurs ont identifié la dispute sous-jacente pendant l'événement. Étant donné qu'il s'agissait d'un problème de conflit plutôt que d'une pénurie de capacités, et que tous les indicateurs de capacité étaient normaux, on ne s'attendait pas à ce que le renforcement de la capacité de base de données le résolve, et l'équipe a étudié d'autres solutions avant de l'appliquer. Cette évaluation a retardé l'atténuation. Réponse Notre équipe d'ingénierie a augmenté la capacité de la base de données touchée. Les temps de réponse et les taux d'erreur sont revenus à la normale immédiatement, et nous avons continué de surveiller pour confirmer que le service était stable avant la fermeture de l'incident. * 13:00 : Les taux d'erreur et les temps de réponse commencent à augmenter pour les clients de la région américaine. * 13:36 : La surveillance automatisée détecte la dégradation et avise l'équipe d'ingénierie sur appel. * 13:36 – 17:29 : Les ingénieurs enquêtent. Tous les indicateurs standard de capacité de la base de données - processeur, mémoire et stockage - restent dans des fourchettes normales, de sorte que la cause n'est pas apparente de la surveillance de routine. * 17:29 : Un incident officiel est déclaré et l'équipe d'intervention complète est engagée. 17:38 Un avis public est publié sur [UiPath Status] (http://status.uipath.com/) \(Enquête\). * 17:31 – 17:43 : Une capacité de base de données supplémentaire est prévue pour la région touchée. * 18:00 : Taux d'erreur, temps de réponse et demande de latence revenir à des niveaux normaux. * 18:11 : La page d'état est mise à jour à la fin de Surveillance & Impact Client. * 19:06 : L'incident est fermé après une surveillance continue confirme que le service est stable. Suivi Pour éviter que cela ne se reproduise, nous sommes : * Modifier les opérations concernées pour qu'elles ne dépendent plus de la ressource partagée. Cette mesure a été appliquée à tous les systèmes touchés et a considérablement réduit la condition qui a causé l'incident. * Permettre une surveillance détaillée de la base de données sur ces systèmes, de sorte que cette classe de contestation est visible alors qu'elle se produit plutôt que par la suite. * Améliorer notre alerte pour qu'une véritable dégradation de ce genre soit clairement distinguable de la variation routinière, autocorrigée, et s'aggrave plus rapidement.

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

1. 6 octobre 2026 à 17:50 UTCinvestigating

   Nous enquêtons sur les rapports d'une panne affectant [fonctionnalité impactée ou symptôme utilisateur] pour Orchestrator en Europe. Impact : Les utilisateurs peuvent s'attendre à des retards dans l'ingestion de registres de robots et/ou la recherche/affichage des registres. Aucun journal ne sera perdu. Prochaine mise à jour: Nos équipes s'efforcent de comprendre la cause et la portée et partageront les mises à jour disponibles.

2. 6 octobre 2026 à 18:28 UTCidentified

   Nous avons identifié la cause d'une panne ayant un impact sur l'ingestion de grumes de robots pour Orchestrator en Europe. Impact : Les utilisateurs peuvent s'attendre à des retards dans l'ingestion de registres de robots et/ou la recherche/affichage des registres. Aucun journal ne sera perdu. Prochaine mise à jour: Nos équipes s'efforcent de comprendre la cause et la portée et partageront les mises à jour disponibles.

3. 6 octobre 2026 à 18:43 UTCmonitoring

   Nous avons atténué le problème de l'ingestion de grumes de robots pour Orchestrator en Europe. Impact : Les utilisateurs peuvent s'attendre à des retards dans l'ingestion de registres de robots et/ou la recherche/affichage des registres. Aucun journal ne sera perdu. Prochaine mise à jour: Nos équipes s'efforcent de comprendre la cause et la portée et partageront les mises à jour disponibles.

4. 6 octobre 2026 à 18:44 UTCresolved

   Nous avons atténué le problème de l'ingestion de grumes de robots pour Orchestrator en Europe. Impact : Les utilisateurs peuvent s'attendre à des retards dans l'ingestion de registres de robots et/ou la recherche/affichage des registres. Aucun journal ne sera perdu. Prochaine mise à jour: Nos équipes s'efforcent de comprendre la cause et la portée et partageront les mises à jour disponibles.

5. 7 octobre 2026 à 11:08 UTCpostmortem

   ## Impact client Sur , entre environ 15:45 UTC et 18:45 UTC, les clients hébergés dans les régions d'Europe, d'Australie et du Japon n'ont pas été en mesure de voir les journaux robots récents dans Orchestrator. Les journaux écrits pendant la fenêtre d'impact n'apparaissaient pas dans les vues Jobs and Logs ni dans l'API Robot Logs, et les journaux plus âgés qu'environ 03:00 UTC ce jour-là n'étaient disponibles que par intermittence. La fenêtre d'impact diffère par région: - Australie: environ 15:45 UTC à 18:35 UTC - Europe: environ 16:35 UTC à 18:00 UTC - Japon: environ 16:45 UTC à 18:30 UTC L'exécution des tâches, les files d'attente, les déclencheurs et toutes les autres fonctionnalités de l'Orchestre n'ont pas été affectées. Aucune trace de robot n'a été perdue. Les journaux produits pendant la fenêtre d'impact ont continué d'être recueillis et sont redevenus visibles une fois le problème atténué. Cause profonde Nous effectuions une mise à niveau programmée du service Elasticsearch qui stocke les registres des robots Orchestor. La mise à niveau utilise une approche bleue/verte : un nouveau cluster est créé à côté du cluster existant, les données y sont restaurées à partir d'une sauvegarde, le pipeline qui ingère de nouveaux logs y est lancé, et seulement alors le trafic est commuté. Dans les régions touchées, le commutateur de circulation a été approuvé par l'ingénieur qui a effectué la mise à niveau avant la restauration des données et le rattrapage par ingestion s'était achevé, ce qui est un écart par rapport à notre procédure de mise à niveau. C'était une erreur humaine. Par conséquent, Orchestrator lisait des journaux de robots provenant d'un cluster qui ne contenait pas encore de données récentes, tandis que de nouveaux journaux continuaient d'être recueillis mais n'étaient pas encore indexés sur les demandes de services de cluster. L'erreur n'a pas été prise parce que notre outil de déploiement repose sur l'opérateur pour vérifier l'exhaustivité des données et ne fait pas respecter l'ordre entre la restauration des données et le commutateur de trafic. Détection Notre monitoring synthétique, qui effectue des tests continus et vérifie le retour de leurs logs, la détection des logs manquants dans les régions touchées et les alertes élevées. Notre équipe d'ingénierie a établi une corrélation entre les alertes et la mise à niveau en cours, a déclaré un incident et a publié un avis de page d'état. Réponse Notre équipe d'ingénieurs a repris le trafic des précédentes grappes Elasticsearch dans les trois régions, qui ont immédiatement rétabli l'accès à tous les journaux de robots, y compris ceux produits pendant la fenêtre d'impact. Nous avons confirmé le rétablissement par une surveillance synthétique dans chaque région touchée et la surveillance continue avant de marquer l'incident résolu vers 18 h 45 UTC. La modernisation des nouvelles grappes se poursuit en arrière-plan. Le trafic ne sera déplacé vers eux qu'après la restauration des données est terminée et l'ingestion est confirmée pour être à jour. Suivi Pour éviter que cela ne se reproduise, nous sommes : - Modifier le pipeline de déploiement de sorte que le commutateur de trafic ne puisse fonctionner tant que les données ne seront pas rétablies et que l'ingestion du nouveau groupe ne sera pas vérifiée. - Ajout d'une étape de retour automatique au pipeline, de sorte que le trafic peut être retourné au cluster précédent en quelques minutes si un problème est détecté après un interrupteur.

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

1. 6 octobre 2026 à 12:38 UTCidentified

   Nous observons des performances dégradées pour les services aux EAU

2. 6 octobre 2026 à 12:43 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

3. 6 octobre 2026 à 14:01 UTCidentified

   Nous avons identifié le problème comme un problème de routage réseau avec un fournisseur de services tiers, affectant la connectivité pour nos services hébergés aux EAU. Nous travaillons avec notre fournisseur en amont sur la résolution et mettrons à jour les progrès réalisés ici.

4. 6 octobre 2026 à 14:22 UTCidentified

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

5. 6 octobre 2026 à 14:51 UTCmonitoring

   Nous surveillons la connectivité et mettrons à jour cette page une fois la stabilité confirmée.

6. 6 octobre 2026 à 15:09 UTCmonitoring

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

7. 6 octobre 2026 à 17:09 UTCresolved

   L'incident a été résolu.

8. 21 octobre 2026 à 05:36 UTCpostmortem

   ## Impact client Entre 12h38 UTC et 14h51 UTC, un sous-ensemble de clients de la région des Émirats arabes unis a connu des défaillances lors de l'accès aux services de cloud UiPath. L'incident a duré environ 2 heures et 13 minutes. Les services touchés comprenaient l'accès à **cloud.uipath.com**, **account.uipath.com** Services hébergés aux Émirats arabes unis. Les clients peuvent avoir rencontré des délais, une authentification défaillante, des connexions de réinitialisation ou des erreurs de serveur. Cause profonde La cause principale était une défaillance du routage du réseau régional chez un fournisseur d'infrastructure tiers. Un sous-ensemble de chemins de réseau sortants de la région de l'UA vers des réseaux externes spécifiques — y compris le réseau de distribution de contenu desservant **cloud.uipath.com** et **account.uipath.com** — a cessé de fournir du trafic. Les nouvelles tentatives de connexion à l'extérieur des services concernés n'ont pas reçu de réponses, ce qui a entraîné l'abandon des demandes. Notre équipe d'ingénierie a exclu la configuration du service UiPath, la politique de niveau d'application et la capacité de connexion sortante comme causes. Le fournisseur d'infrastructure a reconnu un problème connu touchant plusieurs clients sur le même chemin de réseau. Détection Le problème a été détecté par une surveillance automatisée. Vers 12h40 UTC — environ deux minutes après le début de l'échec — l'enquête a confirmé que de nouvelles connexions des services de la région UAN touchés aux principaux paramètres UiPath étaient défaillantes. Réponse À 13h20 UTC, notre équipe d'ingénieurs a confirmé que l'échec se limitait à des itinéraires de réseau spécifiques, tandis que d'autres destinations restaient accessibles. La validation a exclu les changements d'acheminement côté UiPath, les changements de configuration de livraison de contenu, la politique de niveau d'application et les problèmes de capacité de connexion sortante. Un dossier de soutien de haute gravité a été ouvert avec le fournisseur d'infrastructure tiers. À 13h50 UTC, le fournisseur a reconnu un problème connu touchant plusieurs clients. Notre équipe a continué de surveiller la récupération des voies de réseau touchées et de vérifier la santé des services au retour du trafic. À 14h51 UTC, les vérifications de récupération ont confirmé que le trafic d'UiPath à travers les chemins de livraison de contenu touchés était revenu à des niveaux normaux. Des contrôles de santé automatisés et des mesures de service ont confirmé la récupération, et les services en UA étaient opérationnels. Suivi 1. Nous poursuivons les mesures correctives confirmées du fournisseur d'infrastructure et l'analyse des causes profondes de l'échec du routage régional. 2. Nous réexaminons les dépendances de services sortants dans la région touchée afin de renforcer la résilience face à des perturbations similaires de réseaux tiers.

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

1. 2 octobre 2026 à 16:23 UTCinvestigating

   Depuis environ 15h05 UTC, certains clients de la région américaine peuvent voir des emplois qui fonctionnent sur Cloud Robots prendre plus de temps que d'habitude pour commencer, ou rester dans l'état En attente. Les emplois sur vos propres robots ne sont pas affectés, et les autres régions ne le sont pas non plus. Nous avons trouvé la cause probable et nous travaillons pour rétablir le traitement normal des emplois. Les emplois déjà en attente ne sont pas perdus et seront traités une fois le problème résolu. Nous publierons une autre mise à jour dans 60 minutes.

2. 2 octobre 2026 à 16:34 UTCmonitoring

   Nous avons appliqué un correctif pour le problème qui a retardé les emplois sur Cloud Robots dans la région américaine, et les emplois recommencent normalement. Les emplois qui ont été retardés sont maintenant traités. Nous veillons à ce que le service reste stable et afficherons une autre mise à jour dans les 60 minutes.

3. 2 octobre 2026 à 16:51 UTCmonitoring

   Après d'autres travaux sur la question, les emplois sur Cloud Robots dans la région américaine commencent maintenant normalement. Les emplois qui ont été retardés plus tôt sont traités. Nous continuons de surveiller le service et publierons une autre mise à jour une fois le problème résolu.

4. 2 octobre 2026 à 17:03 UTCresolved

   Cette question a été résolue. Entre 15h05 et 16h39 UTC, les emplois sur Cloud Robots dans la région américaine ont été lents à démarrer ou à rester dans l'État en attente. Les emplois commencent normalement depuis 16:39 UTC, et les emplois qui ont été retardés pendant cette période ont maintenant été traités. Nous nous excusons pour la perturbation.

5. 14 octobre 2026 à 14:20 UTCpostmortem

   ## Impact client De 15h00 à 16h38 UTC le 2026-10-02, les emplois de Cloud Robots dans la région américaine ont pris plus de temps que d'habitude pour démarrer, jusqu'à 22 minutes au sommet vers 16h20 UTC. Orchestrator est resté disponible, aucun emploi n'a été perdu, aucune autre région n'a été touchée. Un petit nombre de clients ont reçu une erreur de limite temporaire sur les nouvelles soumissions alors que leurs emplois antérieurs attendaient. Détection Alertes automatisées à 15h07 UTC, sept minutes après le début de l'impact. Les vérifications dans la région des États-Unis ont échoué à environ 15h32 UTC et la réponse à l'incident a commencé. Cause profonde À 14h55 UTC, le flux de travail d'un client a commencé à soumettre des emplois à une vingtaine de fois son taux normal. Le service qui admet les emplois conserve un compte de concordance par client dans la base de données et le met à jour sous un verrou de base de données sur chaque début et fin d'emploi. À ce rythme, la file d'attente pour le dossier du client a augmenté jusqu'à ce que les mises à jour soient terminées. Les mises à jour d'attente ont occupé le pool partagé de travailleurs qui commencent des emplois pour tous les clients de la région, donc les emplois de chaque client attendaient derrière eux. Le mécanisme destiné à isoler la charge d'un client est devenu le goulot d'étranglement. Réponse L'équipe a identifié la voie d'admission surchargée et la charge de travail qui l'accompagne. Un premier changement de configuration à 15h46 UTC a ciblé le mauvais disque et n'a eu aucun effet. Le changement correct à 16:10 UTC a exempté le type de travail de ce client du verrouillage de la base de données et est entré en vigueur vers 16:20 UTC. Les temps de départ sont passés d'environ 13 secondes à moins d'une seconde et l'arriéré d'environ 5200 emplois s'est effondré en 18 minutes. Les débuts de l'emploi étaient normaux à 16h38 UTC. La gâchette du client a été désactivée avec le client vers 16h40 UTC. Suivi La limite de taux verrouillée par la base de données est remplacée par un mécanisme de limitation de taux de rendement élevé en mémoire, de sorte que la charge d'un client ne peut pas bloquer le démarrage du travail pour d'autres. Le changement est complet, testé en préproduction à la même charge, et en cours de déploiement.

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

1. 2 octobre 2026 à 00:13 UTCinvestigating

   Nous enquêtons actuellement sur une panne affectant le portail Insights dans la région des Émirats arabes unis. Les utilisateurs de cette région peuvent ne pas être en mesure d'accéder au portail ou subir des chargements de pages échoués. Notre équipe travaille activement à identifier la cause et à rétablir le service. Nous fournirons une autre mise à jour dès que nous aurons plus d'informations.

2. 2 octobre 2026 à 00:36 UTCidentified

   Nous avons identifié une voie d'atténuation et nous commençons un recul dans la région des Émirats arabes unis. Les utilisateurs peuvent continuer à éprouver des problèmes d'accès intermittents avec le portail Insights pendant que ce travail est en cours. Nous fournirons une autre mise à jour une fois le retour terminé.

3. 2 octobre 2026 à 00:41 UTCmonitoring

   Le portail Insights dans la région des Émirats arabes unis est en cours de chargement après notre retour en arrière. Nous continuons de surveiller le service afin de confirmer la stabilité et nous fournirons une mise à jour finale une fois que nous aurons confiance que la question sera entièrement réglée.

4. 2 octobre 2026 à 00:51 UTCresolved

   Le portail Insights dans la région des Émirats arabes unis fonctionne maintenant normalement après le renversement. Nous avons validé la fonctionnalité du portail clé et confirmé que le service demeure sain. Cet incident est maintenant résolu.

5. 5 octobre 2026 à 22:58 UTCpostmortem

   Impact client Le 1er octobre 2026**, le service UiPath **Insights** dans la région **des Émirats arabes unis** n'était pas disponible. À partir d'environ **23:40 UTC le 1er octobre à 00:39 UTC le 2 octobre**, les utilisateurs n'ont pas pu charger Insights tableaux de bord : les requêtes ont échoué avec une erreur après environ 10 secondes. Les demandes de fourniture ont également échoué. La perturbation a duré environ **59 minutes**. Les autres services UiPath dans la région des Émirats arabes unis et Insights dans toutes les autres régions n'ont pas été touchés. Aucune donnée client n'a été perdue. La cause profonde La panne a été causée par un changement de configuration** qui a été expédié dans une version prévue Insights. Le changement a porté la version **minimum TLS \(Transport Layer Security\)** sur les paramètres d'application Insights dans la région des Émirats arabes unis de TLS 1.2 à **TLS 1.3**, dans le cadre d'un effort de renforcement de la sécurité. La passerelle UiPath qui relie le trafic client à Insights se connecte à ces paramètres sur TLS 1.2. Une fois que les paramètres ont cessé d'accepter TLS 1.2, la passerelle ne pouvait plus ouvrir une connexion sécurisée à eux. Les demandes du client ont retardé et renvoyé des erreurs, même si l'application Insights elle-même est restée saine. Le changement ne s'applique qu'à la région des Émirats arabes unis, raison pour laquelle aucune autre région n'a été touchée. Détection Le problème a été détecté par **UiPath's Automatic Synthetic Monitoring**, qui teste en permanence la disponibilité de plusieurs endroits. Le premier bilan de santé a été enregistré à 23h40 UTC. Des alertes automatisées ont été déclenchées en quelques minutes, et l'équipe d'ingénierie a commencé à enquêter. Réponse L'équipe d'ingénierie a confirmé que la panne n'affectait que Insights dans la région des Émirats arabes unis. L'application fonctionnait normalement, mais aucun trafic client ne l'atteignait. L'équipe a tracé l'échec à l'étape de connexion sécurisée entre la passerelle et Insights, et l'a liée au réglage TLS appliqué par la version. À environ **00:38 UTC**, l'équipe a rétabli la version TLS minimale précédente \(TLS 1.2\) sur les paramètres touchés. Les contrôles synthétiques de santé ont commencé à passer immédiatement, et à partir de **00:41 UTC** tous les contrôles Insights dans la région des Émirats arabes unis étaient sains. L'équipe a continué de surveiller pour confirmer la stabilité totale. Suivi Pour prévenir des incidents similaires à l'avenir, nous prenons les mesures suivantes : * **Supprimer le changement de TLS de la version** afin que les déploiements futurs ne le réappliquent pas, jusqu'à ce que la passerelle supporte TLS 1.3 fin à fin. * **Valider les changements de sécurité de connexion par rapport à la passerelle** dans un environnement de préproduction avant qu'ils ne soient appliqués à la production.

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

1. 1 octobre 2026 à 18:57 UTCinvestigating

   À partir du 1er octobre, vers 13 h 30 UTC, certains agents, y compris les agents à faible code et les agents codés, ont commencé à éprouver des défaillances dans toutes les régions en utilisant gemini-3.1-pro-preview et gpt-4o-2024-05-13. Ces modèles peuvent également ne pas être disponibles pour la sélection pendant la conception de l'agent. Nous enquêtons et travaillons activement sur une solution.

2. 1 octobre 2026 à 19:05 UTCidentified

   Nous avons identifié le problème et déployons une solution. Les agents utilisant les modèles touchés peuvent continuer à subir des défaillances, et les modèles peuvent demeurer indisponibles pour la sélection pendant la conception de l'agent, pendant que le déploiement se termine.

3. 1 octobre 2026 à 19:46 UTCresolved

   Nous avons repris le changement qui a causé ce problème et confirmé que les modèles touchés sont à nouveau disponibles. Certains agents peuvent continuer à subir des défaillances intermittentes pendant que les cas se rafraîchissent. Nous continuons de surveiller la conception et l'exécution d'agents pour gemini-3.1-pro-preview et gpt-4o-2024-05-13.

4. 7 octobre 2026 à 10:15 UTCpostmortem

   ## Impact client Le 1er octobre, 2026, de 14:31 à 19:40 UTC, les agents configurés avec quelques grands modèles de langage, dont Gemini 3.1 Pro Preview et GPT-4o (2024-05-13), n'ont pas démarré dans toutes les régions, avec une erreur disant que le modèle n'est pas disponible. Les mêmes modèles étaient absents de la liste des modèles lors de la conception d'agents. Les agents utilisant d'autres modèles n'ont pas été touchés. Cause profonde Un drapeau de fonction a été retourné, ce qui a fait que le service Agents a commencé à envoyer un code d'opération pour modéliser les demandes de découverte. Cela a fait que la liste des modèles a servi à cette opération spécifique par opposition à la liste des modèles d'agents de base. La liste de modèles par opération a d'abord été créée à partir de la configuration BYOM (Bring Your Own Model) de modèles surridables, ce qui est crucial pour les agents n'a pas la parité avec la liste complète de modèles supportés dans le service Agents. La vérification interne a révélé qu'il s'agissait d'une erreur et non d'une lacune intentionnelle. Au fil du temps, cette lacune n'a jamais été comblée et, après le changement de drapeau, les agents déjà configurés avec l'un des modèles touchés échoueraient en raison de leur absence de la liste retournée. Détection Un client a signalé le problème, et il a été augmenté à nos ingénieurs à 16:44 UTC. Notre surveillance n'a pas alerté, car cette erreur indique habituellement des problèmes de configuration au niveau de l'organisation ou de l'agent. Réponse Les ingénieurs ont tracé les défaillances à la modification de configuration et l'ont retournée à 19:01 UTC. Le retour a pris effet au cours des minutes suivantes, et la dernière défaillance s'est produite à 19h40 UTC. Suivi 1. Les listes de modèles seront alignées avant que cette modification ne se reproduise. 2. Nous changeons la façon dont cette erreur est classifiée donc un pic à l'échelle de la plateforme alerte nos ingénieurs.

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

1. 1 octobre 2026 à 18:17 UTCinvestigating

   À partir du 1er octobre à environ 12h00 UTC, les utilisateurs de la communauté en Europe peuvent éprouver des défaillances dans les agents LowCode qui utilisent des applications d'action locale-solution. Nous avons confirmé que l'impact est limité aux utilisateurs communautaires en Europe. Nous enquêtons activement sur la question, en déterminant l'ampleur des échecs et en travaillant sur une solution.

2. 1 octobre 2026 à 18:25 UTCidentified

   Nous avons identifié le problème qui cause des défaillances dans les agents à faible code qui utilisent des applications d'action locale-solution pour les utilisateurs communautaires en Europe. Nous reculons les changements précédents et continuons de surveiller la reprise. Nous fournirons une autre mise à jour une fois le retour terminé ou si nous avons des informations supplémentaires à partager.

3. 1 octobre 2026 à 20:08 UTCresolved

   Nous avons confirmé que le retour en arrière est terminé et que la question concernant les agents à faible code qui utilisent des applications d'action locale-solution pour les utilisateurs communautaires en Europe a été résolue. Les services se sont rétablis et nous clôturons cet incident.

4. 7 octobre 2026 à 14:28 UTCpostmortem

   ## Impact client Le 1er octobre 2026, de 10h50 à 19h50 UTC, certains utilisateurs de Studio Web en Europe ne pouvaient pas déboguer les agents qui appellent les processus Orchestrator (RPA, agents, etc.) ou les applications Action de la même solution. L'appel a échoué avec une erreur "non trouvée". Les agents publiés et les emplois de production n'ont pas été affectés. Cause profonde Une mise à jour de Studio Web a changé la façon dont les ressources de la solution sont localisées pendant le débogage. Il manquait un paramètre qui maintient le comportement précédent, debug lance donc cherché les ressources de la solution dans l'espace de travail personnel de l'utilisateur au lieu du dossier debug. Détection Les tests automatisés de bout en bout ont alerté nos ingénieurs à 16h43 UTC. La suite de tests de bout en bout fonctionne une fois toutes les 2 heures et l'alerte ne se produit qu'après 3 échecs consécutifs. Le problème a également été signalé dans un environnement client. Réponse Après avoir identifié la cause racine, un retour en arrière a été lancé à 18h00 UTC et était pleinement en vigueur à 19h50 UTC. Cette durée comprenait un échec de déploiement qui a dû être réévalué, ce qui a pris 50 minutes. Une version corrigée incluant le réglage a été déployée le 2 octobre à 13h00 UTC. Suivi 1. Le réglage fait maintenant partie de la ligne de code principale, de sorte que les versions futures l'incluent. 2. Nous améliorons les alertes et la suite de tests de bout en bout pour attraper les régressions plus tôt.

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

1. 1 octobre 2026 à 16:32 UTCresolved

   Entre 14h23 et 16h04 UTC le 1er octobre 2026, certaines demandes de suppression d'éléments dans les services UiPath Automation Cloud dans la région australienne ont échoué avec des erreurs "404 Not Found". Les services concernés comprenaient l'orchestre, la compréhension des documents, le centre d'IA et le service de données. D'autres opérations, comme la visualisation, la création et la mise à jour d'articles, fonctionnaient normalement. La cause était un changement de configuration de notre routage de demande. Nous l'avons roulé et le service est entièrement restauré.

2. 7 octobre 2026 à 10:15 UTCpostmortem

   ## Impact client Entre le 1er octobre 2026 à 14h23 UTC et 16h04 UTC, un sous-ensemble de clients expérimentés **404 Non trouvé** erreurs pour certaines demandes UiPath Automation Cloud dans la région Australie. L'incident a duré 1 heure et 41 minutes. Les requêtes concernées comprenaient des opérations de suppression et certaines vérifications de connexion Robot. Les services touchés comprenaient l'orchestre, la compréhension des documents, le centre d'IA et le service de données. Les emplois de Robot qui ont appelé Orchestrator ont peut-être échoué, et les clients peuvent avoir besoin de réutiliser les emplois de Robot qui ont échoué pendant cette fenêtre. Toutes les autres opérations n'ont pas été touchées. Cause profonde Un changement de configuration d'acheminement a été appliqué à la région de l'Australie avec un ensemble incomplet d'opérations soutenues en raison d'un délai dans le pipeline de libération. Les opérations de suppression étaient absentes de la configuration, de sorte que ces demandes ont été rejetées à la couche de routage avec **404 Not Found** avant d'atteindre les services sous-jacents. Détection La surveillance automatisée de bout en bout a permis de détecter le problème en alertant les défaillances des vérifications du service de Compréhension des documents. Notre équipe d'ingénieurs a ensuite utilisé des données de surveillance interne pour confirmer la tendance générale des défaillances dans les services touchés. Réponse Au cours de l'enquête, les données de surveillance ont montré que les demandes acheminées dans la région de l'Australie revenaient **404 erreurs non trouvées**, tandis que les demandes acheminées dans d'autres régions n'étaient pas touchées. L'analyse a révélé que l'heure de début de l'augmentation de la réponse **404 Not Found** était corrélée avec l'époque où la configuration de routage est entrée en vigueur. L'équipe a renvoyé la configuration de routage à la version de travail précédente. Après le retour, la surveillance a montré que le nombre d'erreurs diminuait d'environ trois minutes, et le service a été entièrement rétabli le 1er octobre 2026 à 16 h 04 UTC. Suivi 1. Améliorer les alertes des couches de routage sur les changements de base 4xx 2. Détecter les configurations de routage partiellement appliquées avant de les faire entrer en vigueur

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

1. 1 octobre 2026 à 13:21 UTCinvestigating

   Notre équipe travaille activement sur un correctif pour la performance dégradée affectant Orchestrator dans la région américaine. Nous partagerons les mises à jour au fur et à mesure des progrès réalisés.

2. 1 octobre 2026 à 14:06 UTCidentified

   Un correctif est actuellement déployé pour la performance dégradée affectant Orchestrator et Action Center dans la région américaine. D'autres mises à jour suivront.

3. 1 octobre 2026 à 14:24 UTCmonitoring

   Un correctif a été mis en place pour les performances dégradées affectant Orchestrator et Action Center dans la région des États-Unis. Notre équipe surveille activement les résultats pour confirmer que le problème est entièrement résolu.

4. 1 octobre 2026 à 17:58 UTCmonitoring

   Un correctif a été mis en place pour les performances dégradées affectant Orchestrator et Action Center dans la région des États-Unis. Nous continuons de surveiller le rendement et la stabilité du système pour confirmer que le problème est entièrement résolu. D'autres mises à jour seront fournies à mesure que de plus amples renseignements seront disponibles.

5. 1 octobre 2026 à 19:03 UTCresolved

   La dégradation des performances affectant Orchestrator et Action Center dans la région américaine a été résolue. La performance du système est demeurée stable après la correction mise en œuvre, et nous poursuivrons la surveillance standard.

6. 5 octobre 2026 à 06:40 UTCpostmortem

   ## Impact client Entre environ 11h00 UTC et 13h40 UTC le 1er octobre 2026, les clients de la région des États-Unis ont observé des temps de réponse plus lents pour les Orchestors et des délais intermittents. Robots a pris plus de temps pour commencer des travaux, traiter des éléments de file d'attente et lire des actifs, et certaines de ces demandes ont échoué. D'autres services UiPath qui s'appuient sur Orchestrator ont également été touchés pendant que Orchestrator était dégradé, et peut avoir vu des réponses plus lentes ou des erreurs. Cause profonde Un déploiement de fixators comprenait un changement de la façon dont la capacité de calcul est réservée et mise à l'échelle pour nos services. Le changement visait à utiliser notre infrastructure plus efficacement, mais il a réduit la capacité de traitement disponible pour Orchestrator. Pendant les périodes de travail, notre mise à niveau automatique n'a pas ajouté de capacité comme prévu, de sorte que le service ne pouvait pas suivre la demande. Détection Notre surveillance interne a détecté le ralentissement après la mise à jour. Notre premier plan était de publier une mise à jour corrigée par le biais de notre processus de publication standard, qui prend plusieurs heures. Lorsque les rapports des clients ont commencé à arriver, nous avons ouvert un incident et nous sommes passés à une correction plus rapide. Réponse Notre équipe d'ingénierie a appliqué les paramètres de capacité précédents directement aux services concernés, sans attendre la mise à jour corrigée. Les temps de réponse sont revenus à la normale vers 13h40 UTC, et nous avons continué à surveiller pour confirmer que le service était stable. Suivi Pour éviter que cela ne se reproduise, nous sommes : - Rétablir définitivement les paramètres de capacité antérieurs et examiner tout changement de capacité futur par rapport à la charge de production avant le déploiement. - Amélioration de la façon dont nous évaluons l'impact client pendant les dégradations, de sorte qu'ils sont augmentés à un incident plus tôt. - Accélérer le retour en puissance et les changements de configuration lorsqu'ils affectent les clients.

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