Historique des pannes de Uipath

1. 3 septembre 2026 à 15:34 UTCinvestigating

   Nous étudions actuellement le problème

2. 3 septembre 2026 à 15:39 UTCidentified

   La question a été cernée et les mesures d'atténuation appropriées ont été mises en oeuvre pour y remédier.

3. 3 septembre 2026 à 15:47 UTCmonitoring

   La question a été résolue avec succès et le service a été entièrement rétabli. Le service fonctionne normalement actuellement.

4. 3 septembre 2026 à 16:17 UTCresolved

   La question a été résolue avec succès et le service a été entièrement rétabli. Le service fonctionne normalement actuellement.

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

1. 4 septembre 2026 à 17:48 UTCresolved

   Le tableau de bord Insights dans Looker a connu un problème qui a empêché les derniers passages Maestro, d'apparaître dans le tableau de bord Régions impactées : États-Unis, SEA, IND, CA, AUE, JP, UK Calendrier des incidents Début: 2 septembre, 2026 à 20:00:00 UTC Résolue : le 4 septembre 2026 à 16h30 UTC Le problème est actuellement résolu, et le tableau de bord Insights affiche les dernières données d'exécution Maestro.

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

1. 1 septembre 2026 à 13:49 UTCinvestigating

   Nous enquêtons sur des rapports de performance dégradée ayant une incidence sur la numérisation et l'extraction pour la compréhension des documents et la PSI aux États-Unis. Impact : Les utilisateurs peuvent éprouver une lenteur et avoir échoué. Nos équipes travaillent à identifier la cause et partageront plus de détails au fur et à mesure que l'enquête avance.

2. 1 septembre 2026 à 14:07 UTCmonitoring

   Nous avons cerné la question et appliqué une mesure d'atténuation. Les services sont rendus à l'état sain et nous surveillons les services.

3. 1 septembre 2026 à 15:06 UTCresolved

   Cette question a été entièrement résolue et les services sont maintenant stables. Nous publierons plus de détails sur l'incident sur la page d'état bientôt.

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

1. 31 août 2026 à 16:55 UTCinvestigating

   Nous enquêtons actuellement sur la question.

2. 31 août 2026 à 17:07 UTCidentified

   Nous avons identifié le problème et mis en œuvre la correction nécessaire

3. 31 août 2026 à 18:24 UTCmonitoring

   La question a été atténuée et le service est actuellement opérationnel. Nous continuerons de surveiller de près la santé des services et de prendre des mesures supplémentaires si nécessaire.

4. 31 août 2026 à 19:39 UTCresolved

   La question a été atténuée et le service est actuellement opérationnel. Nous continuerons de surveiller de près la santé des services et de prendre des mesures supplémentaires si nécessaire.

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

1. 28 août 2026 à 15:41 UTCidentified

   Le problème a été identifié et l'équipe travaille activement au déploiement d'une solution. Nous nous attendons à ce que le déploiement commence dans les prochaines heures.

2. 28 août 2026 à 17:27 UTCmonitoring

   Nous avons identifié la cause profonde de la dégradation des performances et nous sommes en train de déployer une correction dans les prochaines heures. Il affecte les requêtes liées où l'utilisateur n'a pas accès au dossier original. La surface de l'API n'est pas affectée. L'exportation via CSV peut être utilisée comme solution de rechange. D'autres mises à jour seront fournies au fur et à mesure que nous nous dirigeons vers la résolution.

3. 28 août 2026 à 17:39 UTCidentified

   Nous avons identifié la cause profonde de la dégradation des performances et nous sommes en train de déployer une correction dans les prochaines heures. Il affecte les requêtes liées où l'utilisateur n'a pas accès au dossier original. La surface de l'API n'est pas affectée. L'exportation via CSV peut être utilisée comme solution de rechange. D'autres mises à jour seront fournies au fur et à mesure que nous nous dirigeons vers la résolution.

4. 28 août 2026 à 20:00 UTCidentified

   La correction est actuellement appliquée. Nous fournirons une autre mise à jour peu après le déploiement dans toutes les régions touchées.

5. 28 août 2026 à 22:57 UTCresolved

   La correction a été déployée avec succès dans toutes les régions et nous avons confirmé que le problème était résolu. Le service fonctionne comme prévu.

6. 3 septembre 2026 à 08:49 UTCpostmortem

   ## Impact client Entre le 28 août 2026 à 15h23 UTC et le 28 août 2026 à 22h57 UTC, un sous-ensemble de clients ont éprouvé des erreurs lors de l'ouverture de la file d'attente détails panneaux dans Orchestrator. Le chemin affecté a retourné une page 404 pour les files d'attente LINKED lorsque l'utilisateur n'avait PAS accès au dossier original dans lequel les éléments ont été créés. L'impact n'a affecté que les interactions de l'interface utilisateur Orchestrator et s'est étendu à toutes les régions exécutant la version du logiciel touché. L'accès à l'interface de programmation de l'application Orchestrator n'était pas affecté, et l'exportation des données de la file d'attente vers CSV était disponible comme solution de rechange. La durée totale était d'environ 7 heures. Cause profonde L'incident a été causé par une régression dans l'interface utilisateur Orchestrator pour les files d'attente liées à d'autres dossiers. La régression n'a pas géré correctement le flux des détails de la file d'attente liée lorsque l'utilisateur demandeur n'a pas eu accès au dossier original, ce qui a amené le panneau des détails de l'élément de file d'attente à se diriger vers une page 404 au lieu d'afficher les informations attendues. Détection Le problème a été détecté lors d'une alerte d'incident automatisée pour l'orchestor le 28 août 2026 à 15h23 UTC. Réponse À 15 h 31 UTC le 28 août 2026, notre équipe d'ingénieurs a décrit le problème comme étant des clients incapables d'accéder aux panneaux de détails des éléments de file en raison d'une régression. À 15 h 41 UTC, une mise à jour publique a confirmé que la cause principale avait été identifiée, qu'une correction était en cours de déploiement et que l'accès à l'interface de programmation de l'application n'était pas affecté. À 17h27 UTC, la portée a été limitée aux files d'attente liées où l'utilisateur n'avait pas accès au dossier original. À 17 h 29 UTC, l'équipe a déterminé que la correction initiale n'abordait pas entièrement le scénario touché, et une correction a été élaborée. À 17 h 30 UTC, le scénario touché a été reproduit et la correction corrigée a été validée localement. À 17h39 UTC, une mise à jour de la page d'état documentée CSV export comme solution de rechange. Le déploiement de la correction corrigée s'est poursuivi dans les régions touchées. À 22h50 UTC, la correction a été confirmée partout. À 22 h 57 UTC, l'incident a été marqué et la page d'état a été mise à jour pour confirmer que le service fonctionnait comme prévu. Suivi Les mesures officielles de suivi font l'objet d'un suivi dans le cadre du processus d'examen postincident amorcé à la résolution. Éléments d'action - Élargir nos cas de tests automatisés pour inclure ce scénario, et d'autres scénarios similaires liés à des objets liés ou à des scénarios croisés. - S'assurer que nous pouvons désactiver en toute sécurité tout changement via un drapeau pour un temps de réponse plus rapide.

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

1. 27 août 2026 à 17:16 UTCinvestigating

   Nous enquêtons sur les rapports concernant des traces de robots manquantes dans la région américaine. Nos équipes travaillent à identifier la cause et partageront plus de détails au fur et à mesure que l'enquête avance.

2. 27 août 2026 à 18:53 UTCidentified

   Nous avons constaté que l'ingestion des robots était retardée. Les journaux de robots rattrapent les données en direct et nous surveillons la récupération.

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

   Les journaux sont maintenant remplis comme prévu en temps réel et nous continuerons à surveiller l'application.

4. 27 août 2026 à 21:57 UTCresolved

   Le problème a été résolu et les journaux sont en cours de constitution comme prévu.

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

1. 25 août 2026 à 09:41 UTCidentified

   Nous avons identifié un problème affectant la fonctionnalité de déploiement de solutions dans Studio Web dans la région du Japon, où les déploiements de solutions peuvent échouer. Un correctif a été préparé et sera déployé sous peu. Nous fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 25 août 2026 à 09:47 UTCmonitoring

   La solution a été déployée avec succès dans la région du Japon et la question a été atténuée. Nous surveillons de près le service pour nous assurer que le déploiement des solutions continue de fonctionner comme prévu et nous fournirons d'autres mises à jour au besoin.

3. 25 août 2026 à 10:12 UTCresolved

   Le problème a été résolu, et le déploiement de Solution dans Studio Web fonctionne comme prévu dans la région du Japon. Aucun autre impact n'a été observé.

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

1. 25 août 2026 à 03:58 UTCinvestigating

   Nous enquêtons sur un problème touchant les clients utilisant Insights dans la région de Singapour, où les tableaux de bord peuvent ne pas charger et afficher des erreurs de timeout. Nos équipes s'efforcent d'identifier la cause fondamentale et fourniront d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 25 août 2026 à 04:37 UTCmonitoring

   La question a été atténuée et nous suivons de près le service Insights dans la région de Singapour pour nous assurer que les tableaux de bord continuent de se charger comme prévu.

3. 25 août 2026 à 04:53 UTCresolved

   La question a été réglée et le service Insights dans la région de Singapour fonctionne comme prévu. Aucun autre impact n'a été observé.

4. 4 septembre 2026 à 11:46 UTCpostmortem

   ## Impact client Entre le 25 août 2026 à 3:42 h UTC et le 25 août 2026 à 4:53 h UTC, les clients utilisant Insights dans la région de Singapour ont subi des défaillances en chargeant des tableaux de bord Insights. Les utilisateurs touchés ont vu les pages du tableau de bord s'éteindre ou ne pas se charger, et des erreurs de serveur ont été observées pour les demandes de service connexes. L'impact principal a été l'accès au tableau de bord Insights, y compris les cartes et alertes. Un service connexe a également retourné les erreurs du serveur pendant l'incident, mais l'accès au tableau de bord s'était rétabli avant la résolution finale. Cause profonde L'incident a été attribué à une perturbation régionale du service Microsoft à Singapour affectant l'infrastructure utilisée par le service Insights. Pendant la perturbation, le service Insights n'a pas été en mesure de répondre de façon fiable aux demandes du tableau de bord, ce qui a entraîné des délais de requête et des erreurs de serveur. Aucun changement n'a été apporté de notre côté. Le service s'est rétabli à mesure que la perturbation régionale de Microsoft a été résolue, et Microsoft a par la suite signalé un problème de service régional à Singapour sur sa page d'état. Une analyse officielle des causes profondes a été demandée à Microsoft pour confirmer le mécanisme de défaillance spécifique et identifier toute mesure préventive ou d'atténuation supplémentaire. Détection La surveillance automatisée de la santé pour le service Insights a permis de détecter le problème le 25 août 2026 à 3:42 h UTC. L'impact client a été confirmé sur le pont de réponse peu après la détection. Réponse Le 25 août, 2026 à 3:58 h UTC, nous avons publié une mise à jour publique indiquant que les tableaux de bord Insights dans la région de Singapour pourraient ne pas charger et afficher des erreurs de temps. Pendant la réponse, notre équipe d'ingénierie a vérifié les erreurs de serveur dans la surveillance automatisée, tenté d'accéder aux diagnostics de service, et a commencé une procédure de récupération sur l'infrastructure sous-jacente. Au 25 août 2026, à 4 h 01 UTC, le service Insights s'est rétabli pendant que la procédure de récupération était en cours, et le chargement du tableau de bord a été validé sur plusieurs comptes d'essai. Au 25 août 2026 à 4h37 UTC, nous avons déplacé l'incident à la surveillance après avoir confirmé les tableaux de bord chargés avec succès. Un service de soutien connexe a été récupéré le 25 août 2026 à 4:49 h UTC, et l'incident a été marqué résolu le 25 août 2026 à 4:53 h UTC. Suivi 1. Demander à Microsoft d ' analyser les causes profondes de la perturbation régionale de Singapour qui affecte le problème de chargement des tableaux de bord.

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

1. 25 août 2026 à 03:44 UTCinvestigating

   Nous enquêtons sur un problème touchant les clients qui utilisent la fonctionnalité OCR étendue dans le service de compréhension de documents dans la région de Singapour. Nos équipes s'efforcent d'identifier la cause fondamentale et fourniront d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 25 août 2026 à 04:04 UTCmonitoring

   La question a été atténuée et nous surveillons de près le service pour nous assurer qu'il continue de fonctionner comme prévu. Nous fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

3. 25 août 2026 à 04:59 UTCresolved

   Le problème a été résolu et le service fonctionne comme prévu. Aucun autre impact n'a été observé.

4. 27 août 2026 à 03:42 UTCpostmortem

   ## Impact client Le 25 août 2026, les demandes prolongées de ROC dans le service d'entente de documents ont échoué avec 500 codes de statut dans la région de Singapour pendant environ 33 minutes, entre 03:08 et 03:41 UTC. La cause était une perturbation des services régionaux de Microsoft à Singapour. Toutes les autres fonctions de compréhension des documents n'étaient pas affectées, et aucune autre région n'a été touchée. Cause profonde L'échec a été attribué à une perturbation régionale du service Microsoft à Singapour affectant les ressources utilisées par la capacité élargie de ROC. Aucun changement n'avait été apporté de notre côté, et Microsoft a par la suite mis à jour sa propre page de statut pour refléter un problème régional de Singapour. Une analyse formelle des causes profondes a été demandée à Microsoft. Détection Une alerte automatisée pour le service de compréhension des documents a été déclenchée le 25 août 2026 à 3 h 13 UTC. L'alerte a été rapidement reconnue et l'incident a été déclaré touchant le client en quelques minutes. Réponse L'ingénieur sur appel a étendu l'impact sur la région de Singapour. Les répondants ont exclu une récente mise à jour des services comme cause, car la même mise à jour avait été déployée dans d'autres régions sans impact comparable, ce qui faisait état d'une défaillance de la dépendance régionale en dehors de notre infrastructure. Comme l'échec est survenu dans un service Microsoft en amont, aucune mesure d'atténuation n'était disponible ou requise du côté UiPath. Les demandes ont commencé à réussir à nouveau à 03:41 UTC que la dépendance Microsoft récupéré. Les intervenants ont tenu l'incident ouvert pour vérifier un rétablissement soutenu : dix minutes de trafic propre ont été confirmées à 03h51 UTC, l'incident a été transféré à Surveillance à 04h04 UTC, et il a été résolu à 04h59 UTC après une stabilité continue sans autres défaillances. Suivi 1. A demandé à Microsoft d ' analyser les causes profondes de la perturbation régionale de Singapour affectant les dépendances élargies de l ' OCR, y compris les moyens de prévenir la récurrence.

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

1. 24 août 2026 à 10:43 UTCidentified

   Nous avons identifié la cause d'un problème touchant un petit nombre de clients utilisant les applications UiPath créées par le service Web Studio dans plusieurs régions. Nos équipes sont prêtes avec une solution, et le déploiement est sur le point de commencer dans les régions touchées. Nous continuerons de surveiller le déploiement et de fournir d'autres mises à jour au fur et à mesure que la correction entrera en vigueur.

2. 24 août 2026 à 11:30 UTCmonitoring

   La correction a été déployée avec succès dans toutes les régions touchées, et la question a été atténuée. Nous surveillons de près le service pour nous assurer que le correctif continue de fonctionner comme prévu et nous fournirons d'autres mises à jour au besoin.

3. 24 août 2026 à 11:55 UTCresolved

   Le problème a été résolu et le service fonctionne comme prévu. Aucun autre impact n'a été observé.

4. 1 septembre 2026 à 11:47 UTCpostmortem

   ## Impact client Entre le 19 août 2026 à 14h33 UTC et le 24 août 2026 à 11h30 UTC, un sous-ensemble de clients n'a pas pu charger les projets UiPath Apps de Studio Web. Les clients touchés ont éprouvé l'indisponibilité complète des projets Apps plutôt que la lenteur ou la performance dégradée. L'impact a été limité à un petit ensemble de clients, dont le service Apps a été hébergé dans la région du Japon. La durée totale impactée par le client était d'environ 4 jours et 21 heures. Cause profonde La cause principale était une inadéquation de déploiement entre Studio Web et UiPath Apps. Le 19 août 2026, Studio Web a reçu une mise à jour prévue dans la région de l'UE qui comprenait une mise à jour du cadre. La mise à jour correspondante des applications UiPath contenant la mise à niveau du cadre n'avait pas encore été déployée au Japon. Une mise à jour antérieure des applications, déjà compatible avec la nouvelle version-cadre, avait été déployée dans toutes les régions, sauf au Japon, où le déploiement avait été reporté pour des raisons indépendantes. En conséquence, la région du Japon était toujours en train de lancer une ancienne version d'applications qui n'était pas compatible avec le Studio Web mis à jour. Détection La question a été signalée par un client par l'intermédiaire de son équipe de compte UiPath le 24 août 2026 à 9h36 UTC. Un incident a été ouvert à 10 h 21 UTC, et un incident sur la page du statut public a été déclaré dans une minute. La surveillance automatique existante n'a pas détecté le problème parce qu'elle valide les combinaisons de déploiement correspondantes; l'amélioration de la détection des configurations mixtes fait partie de notre plan de suivi. Réponse Quelques minutes après l'ouverture de l'incident, nous avons identifié l'inadéquation du déploiement comme cause principale et avons décidé d'accélérer le déploiement de la mise à jour UiPath Apps correspondante dans toutes les régions touchées, en alignant les applications avec la version Web de Studio déjà servie aux clients touchés. À 10 h 43 UTC, nous avons affiché une mise à jour publique confirmant que la cause avait été identifiée et que la correction était déployée. À 10 h 52 UTC, le déploiement était en cours pour les autres régions, plusieurs régions étant déjà terminées. À 11 h 30 UTC, nous avons confirmé que la correction avait été déployée dans toutes les régions touchées et que l'incident avait été atténué. À 11 h 55 UTC, après que la surveillance n'a révélé aucun autre impact, l'incident a été marqué résolu. Suivi 1. Ajouter une alerte automatisée sur la télémétrie de production pour détecter les défaillances de charge des applications en corrélation avec la version Web de Studio qui est desservie. 2. Mettre en œuvre une surveillance synthétique qui charge régulièrement un projet d'applications créé depuis Studio Web à travers des configurations client représentatives et des alertes en cas d'échec. 3. Ajustez le séquençage de la version pour les modifications de Studio Web et Apps étroitement couplées afin que les mises à jour d'applications dépendantes soient pleinement déployées dans toutes les régions avant que la nouvelle expérience Studio Web atteigne le trafic client.

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

1. 21 août 2026 à 12:37 UTCmonitoring

   Un correctif a été mis en place pour la question de la classification et de l'extraction des documents pour la compréhension des documents aux États-Unis, et nous suivons actuellement les résultats.

2. 21 août 2026 à 13:36 UTCresolved

   La question de la classification et de l'extraction des documents pour la compréhension des documents dans la région des États-Unis a été résolue. Après une période de surveillance, le service est confirmé en bonne santé et fonctionne normalement.

3. 27 août 2026 à 03:46 UTCpostmortem

   ## Impact client Entre le 21 août 2026 à 11h05 UTC et le 21 août 2026 à 12h18 UTC, un sous-ensemble de clients ont connu des opérations de compréhension de documents échouées, y compris la classification, l'extraction et la numérisation des documents. La durée estimée de la panne partielle était de 48 minutes. L'impact a été limité aux clients utilisant Document Understanding dans la région des États-Unis. Cause profonde L'incident a été causé par la configuration de sauvegarde de la base de données Document Understanding qui a pénétré dans un état rompu lors d'une opération de mise à niveau préventive de la base de données. L'augmentation a été amorcée après que la base de données a approché sa limite de stockage. Au cours de l'opération, la base de données secondaire n'a pas pu être mise à l'échelle, la tentative de suppression de la configuration de rupture a échoué et le fournisseur de plate-forme de base de données a dû briser le lien de réplication. Cela a laissé la configuration de rupture dans un état temporaire non disponible, ce qui a causé le stockage et les services d'exécution qui dépendent de cette base de données pour échouer les requêtes. Détection L'incident a été détecté au moyen d'une alerte automatisée pour les services de compréhension des documents, qui a été reconnue le 21 août 2026 à 12 h 10 UTC. Réponse Avant la déclaration de l'incident ayant un impact sur le client, la mise à niveau de la base de données primaire a été achevée et l'appui du fournisseur de plate-forme de base de données a été sollicité pour le problème de base de données secondaire. Après la rupture de la configuration, nous avons exploré la possibilité de rediriger la connexion du service, mais nous n'avons pu identifier un chemin sûr et immédiat pour le faire compte tenu de la configuration actuelle du service. Le service a été restauré en supprimant la base de données secondaire malsaine et en recréant la configuration d'échec. Le 21 août 2026 à 12h37 UTC, la correction avait été mise en œuvre et le suivi était en cours. À 13 h 36 UTC, la surveillance a confirmé que le service était en bonne santé et que l'incident était résolu. Suivi 1. Demander une analyse des causes profondes au fournisseur de la plate-forme de base de données pour déterminer pourquoi la base de données secondaire n'a pas pu être mise à l'échelle et pourquoi l'assainissement de la configuration de rupture a nécessité la rupture de la réplication. 2. Mettre à jour les seuils d'alerte et le routage de la base de données afin que les alertes soient assignées et appliquées plus tôt, y compris un avertissement de gravité inférieure à 75 % d'utilisation et une alerte de gravité supérieure à 85 %.

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

1. 19 août 2026 à 16:34 UTCinvestigating

   Nous enquêtons sur un problème qui pourrait affecter certains clients utilisant Claude Sonnet 4.6 chez Agents dans la région américaine. Notre équipe d'ingénieurs s'emploie activement à comprendre le problème et partagera d'autres mises à jour au fur et à mesure que de plus amples renseignements seront disponibles.

2. 19 août 2026 à 16:40 UTCmonitoring

   Nous avons atténué le problème. Notre équipe d'ingénierie est active le matin et partagera d'autres mises à jour au fur et à mesure que de plus amples informations seront disponibles.

3. 19 août 2026 à 16:42 UTCmonitoring

   Nous avons atténué le problème. Notre équipe d'ingénierie surveille activement et partagera d'autres mises à jour au fur et à mesure que de plus amples informations seront disponibles.

4. 19 août 2026 à 16:55 UTCresolved

   La question a été réglée.

5. 31 août 2026 à 12:41 UTCpostmortem

   Impact client Entre le 19 août 2026 à 13h36 UTC et le 19 août 2026 à 15h53 UTC, un sous-ensemble de clients a reçu des erreurs lors de l'utilisation de Claude Sonnet 4.6 chez Agents. L'impact a duré environ 2 heures et 17 minutes. L'impact a été pour les clients utilisant Agents dans la région américaine. Des erreurs ont également été observées pour Claude Opus 4.6 et Claude Opus 4.5, qui sont utilisés à un volume inférieur. --- La cause profonde Dans le cadre d'une migration planifiée de l'infrastructure, nous avons déplacé le service de plate-forme qui oriente les demandes d'Agents vers un nouveau système de configuration, région par région. La nouvelle source de configuration manquait les entrées de routage de trois modèles Claude : Claude Sonnet 4.6, Claude Opus 4.6 et Claude Opus 4.5. Sans ces entrées, le service n'a pu résoudre une destination valide pour les demandes de ces modèles, et les a rejetées avec des erreurs. D'autres modèles n'ont pas été modifiés et ont continué à servir normalement. --- Détection Le problème a été détecté par l'escalade des clients le 19 août 2026 à 14 h 55 UTC — environ 1 heure et 19 minutes après la première demande touchée. Notre équipe d'ingénieurs a étendu la question à des modèles spécifiques de Claude et a commencé à enquêter. La communication du statut public a commencé à 15 h 08 UTC. Notre surveillance d'alerte est basée sur les taux d'erreur agrégés. Bien que presque toutes les demandes adressées aux trois modèles touchés aient échoué, ces modèles représentaient une faible part du trafic total dans la région, de sorte que le signal global n'a pas franchi nos seuils d'alerte et que la question n'a pas été soulevée automatiquement. Il s'agit de l'écart de détection traité dans le suivi ci-dessous. --- Réponse À 15 h 25 UTC, la source de configuration incomplète a été identifiée comme la cause et une correction a été lancée. À 15 h 47 UTC, le déploiement du correctif était en cours, et le service a été activement surveillé au fur et à mesure que le changement se déroulait. À 15 h 59 UTC, les registres de service ont confirmé que le problème était atténué et à 16 h UTC, le taux de défaillance a été confirmé à 0 %. L'incident a été marqué atténué à 16h40 UTC, et la résolution complète a été déclarée à 16h55 UTC après la surveillance continue et la confirmation par le client que le service fonctionnait comme prévu. --- Suivi La migration de l'infrastructure a été achevée dans toutes les régions et la configuration du routage provient maintenant d'une seule source, ce qui élimine l'inadéquation qui a causé cet incident et ne peut donc pas se reproduire. Des contrôles automatisés sont mis en place pour vérifier en permanence chaque modèle pris en charge dans chaque région, de sorte qu'un modèle non disponible est détecté et alerté immédiatement, y compris dans les régions à faible trafic.

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

1. 18 août 2026 à 17:54 UTCinvestigating

   Nous enquêtons sur les rapports d'une panne d'impact dans les évaluations d'expression liées aux paramètres de sortie des tâches HITL pour Asgentic Orchestratron chez les utilisateurs communautaires en Europe. Impact: Les utilisateurs peuvent ne pas être en mesure de remplir les 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. 18 août 2026 à 20:31 UTCidentified

   Nous avons identifié la cause d'une panne impactant les évaluations d'expression liées aux paramètres de sortie des tâches HITL pour l'Orchestration Agentique chez les utilisateurs communautaires en Europe. Impact : Les utilisateurs subiront des échecs lorsqu'ils auront un paramètre de sortie de tâches HITL. Prochaine mise à jour: Nos équipes s'efforcent de comprendre la cause et la portée et partageront les mises à jour disponibles.

3. 18 août 2026 à 21:45 UTCidentified

   Nous avons identifié la solution et la résolution est en cours. Prochaine mise à jour: Nos équipes travaillent sur le correctif et partageront les mises à jour disponibles.

4. 18 août 2026 à 22:53 UTCmonitoring

   Nous avons déployé la solution et nous suivons la résolution. Prochaine mise à jour : Nos équipes surveillent la résolution et partageront les mises à jour disponibles.

5. 18 août 2026 à 23:25 UTCresolved

   La panne a été résolue et l'Orchestration Agentique est pleinement opérationnelle. Impact: Aucun impact utilisateur en cours.

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

1. 18 août 2026 à 12:08 UTCidentified

   Nous avons identifié la cause profonde d'un problème dans Studio Web où l'écran de configuration des ressources pour modifier les attributs des ressources ne se charge pas. Nous déployons une solution.

2. 18 août 2026 à 13:05 UTCidentified

   Le déploiement de la solution est en cours. Nous fournirons d'autres mises à jour à mesure que le déploiement progressera.

3. 18 août 2026 à 14:06 UTCidentified

   La correction a été vérifiée et est appliquée dans toutes les régions restantes. Nous surveillons le déploiement et le rétablissement. Merci de votre patience.

4. 18 août 2026 à 17:03 UTCidentified

   Le déploiement progresse comme prévu dans les autres régions. Nous continuons de surveiller le déploiement. Merci de votre patience.

5. 18 août 2026 à 18:12 UTCmonitoring

   Le déploiement progresse comme prévu dans les autres régions. Nous continuons de surveiller le déploiement. Merci de votre patience.

6. 18 août 2026 à 19:05 UTCresolved

   Le déploiement est terminé et la question doit être réglée.

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

1. 18 août 2026 à 05:32 UTCinvestigating

   Nous enquêtons sur une question touchant les comptes communautaires où les entités nouvellement créées peuvent prendre environ une heure pour apparaître dans Studio Web. Aucune donnée n'est perdue et les entités existantes ne sont pas affectées.

2. 18 août 2026 à 06:48 UTCinvestigating

   Nous continuons d'étudier la question et nous travaillons à identifier la cause fondamentale et à rétablir les délais de traitement normaux.

3. 18 août 2026 à 08:44 UTCinvestigating

   Nous continuons d'étudier la question touchant un sous-ensemble de locataires en Europe, aux États-Unis et au Japon, où les entités nouvellement créées pourraient prendre plus de temps que prévu pour apparaître dans Studio Web. Aucune donnée n'est perdue et les entités existantes ne sont pas affectées.

4. 18 août 2026 à 09:37 UTCidentified

   Nous avons identifié la cause et nous travaillons sur une résolution de la question touchant un sous-ensemble de locataires en Europe, aux États-Unis et au Japon. Merci de votre patience.

5. 18 août 2026 à 11:19 UTCmonitoring

   La question a été atténuée et nous nous attendons à ce que les délais de traitement reviennent à la normale sous peu. Nous surveillons la reprise de près. Merci de votre patience.

6. 18 août 2026 à 11:57 UTCresolved

   Le problème a été résolu et le temps de traitement est revenu à la normale. Merci de votre patience.

7. 27 août 2026 à 03:51 UTCpostmortem

   ## Impact client Entre le 18 août 2026 à 5h11 UTC et le 18 août 2026 à 11h57 UTC, les entités nouvellement créées dans un sous-ensemble de locataires UiPath Cloud pourraient prendre plus de temps que prévu pour apparaître dans Studio Web. Au moment de l'évaluation initiale, les entités nouvellement créées paraissaient avec un délai d'environ une heure. Les clients en Europe, aux États-Unis et au Japon ont été touchés. La création d'entités s'est poursuivie avec succès, aucune donnée n'a été perdue et les entités existantes n'ont pas été affectées. Cause profonde La question a été causée par un volume exceptionnellement élevé de demandes de création d'actifs émanant d'un locataire. Ces demandes ont généré plus d'événements que notre service d'indexation d'entités de backend pourrait traiter au même rythme, créant un arriéré dans la file d'attente de traitement d'événements. Comme Studio Web compte sur ce service pour afficher les entités nouvellement créées, de nouvelles entités sont apparues seulement après le traitement de l'arriéré. Détection Le problème a été identifié par notre équipe d'ingénierie par l'alerte de latence de traitement des entités, et un incident a été déclaré à 5h11 UTC le 18 août 2026. À 5 h 23 UTC, l'analyse a confirmé que la dernière entité traitée avait environ une heure de retard. Réponse À 5h32 UTC, nous avons publié une mise à jour client initiale indiquant une visibilité retardée pour les entités nouvellement créées dans Studio Web. Par 6h07 UTC, l'enquête a permis d'identifier un trafic exceptionnellement élevé de création d'actifs par un locataire, et à 7h03 UTC, nous avons ajusté les ressources de base de données pour le service touché afin d'aider le traitement à récupérer. À 7h59 UTC, la source du volume de demandes élevé avait cessé d'envoyer des demandes, et la file d'attente a commencé à s'épuiser. À 9h59 UTC, nous avons commencé un processus de synchronisation des données pour le locataire touché, et à 10h31 UTC, nous avons supprimé les événements en attente problématiques afin que le traitement normal puisse rattraper plus rapidement. La profondeur des files d'attente est passée de 95 000 articles à 8 h 34 UTC à 1 000 articles à 11 h 44 UTC. L'incident a été marqué atténué à 11 h 19 UTC après que le traitement a été récupéré substantiellement, et résolu à 11 h 57 UTC après que le temps de traitement est revenu à la normale. Suivi Redémarrer la synchronisation des données pour le locataire touché et surveiller l'ingestion jusqu'à ce que les données du locataire soient confirmées. Améliorer la gestion de l'entité dans le moteur d'indexation afin que l'arriéré ne s'accumule pas à ce rythme.

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

1. 14 août 2026 à 21:24 UTCidentified

   We have identified the cause of the degraded performance impacting Orchestrator in US region and are working on mitigation. Impact: Users may experience delayed loads and views on Orchestrator Robot logs. Additional updates will be provided as we move toward resolution.

2. 14 août 2026 à 23:22 UTCresolved

   The issue has been resolved and Orchestrator Robot logs performance has returned to expected levels after degraded performance impacted Robot logs to load in US region. Impact: No ongoing user impact.

3. 28 août 2026 à 16:55 UTCpostmortem

   ## Customer impact Between August 14, 2026 at 8:54 pm UTC and August 15, 2026 at 2:09 AM UTC, a subset of customers in the US region experienced significant slowness in the Orchestrator Jobs and Logs pages, and robot logs appeared later than expected in the logs view. Performance had substantially recovered by 11:22 PM UTC on August 14, with full recovery confirmed with affected customers at 2:09 AM UTC on August 15. Automation execution was not affected, jobs continued to be scheduled and to run normally throughout. No log data was lost. Logs continued to be recorded and became visible once the system caught up. Requests did not fail, so no errors were surfaced, pages were slow to load and recent activity appeared missing or delayed. No other region was impacted. ## Root cause Orchestrator stores and retrieves robot logs using a dedicated search and storage system. Routine maintenance on that system causes data to be redistributed internally across the cluster. Our analysis indicates that a redistribution larger than anticipated consumed capacity that would otherwise have served customer requests, slowing both the retrieval of existing logs and the processing of new ones. This accounts for the majority, but not the entirety, of the slowdown observed, and analysis of the remaining contributing factor is continuing. Capacity returned to normal without intervention, at which point log visibility and page performance recovered. ## Detection The issue was surfaced through customer reports of slow Jobs and Logs pages in the US region. ## Response We posted a status update confirming that we were investigating degraded Orchestrator performance in the US region. Our engineering team scoped the impact to the US region and narrowed the slowdown to the log storage and search layer. The degradation stemmed from capacity contention that eased as the redistribution completed, and responders monitored the system through recovery. Page performance and log visibility returned to expected levels over the course of the evening, and recovery was subsequently confirmed with affected customers at 2:09 AM UTC on August 15. ## Follow up 1. We are adding monitoring and alerting on the response times customers experience and on the delay between a robot log being generated and becoming visible, so that degradation of this kind is detected proactively. 2. We are documenting an operational procedure that gives our on-call engineers defined steps to reduce customer impact during this class of degradation. 3. We are changing how routine maintenance on the log storage system is scheduled and paced in the US region so that it does not affect customer-facing performance. 4. We are increasing spare capacity in the log storage system so that internal data movement has room to complete without competing with customer requests.

1. 18 août 2026 à 10:58 UTCresolved

   Une tempête de requêtes sur un modèle rarement utilisé dans IXP Communications Mining a provoqué une boucle de réessayer pour verrouiller les requêtes synchrones dans l'API IXP plus large. Cela a causé des demandes d'échec avec 500's car les travailleurs étaient occupés par des demandes de longue durée. La mise à niveau automatique a rapidement atteint sa capacité maximale et la résolution n'a été faite qu'en appliquant un correctif de code qui a introduit des délais stricts pour la requête API contributive. La tempête de demande a commencé vers 15:10 UTC et a détecté un 15:15 UTC par des alarmes automatiques. La résolution a été confirmée vers 18h15 UTC. L'incident a d'abord été attribué à tort au seul client qui a fait la tempête des demandes, mais a été découvert plus tard pour avoir touché un plus grand nombre d'utilisateurs. Impact total limité à une poignée d'utilisateurs aux États-Unis.

2. 18 août 2026 à 21:25 UTCpostmortem

   Impact client Le 12 août 2026, entre 15 h 10 et 18 h 15 UTC, les utilisateurs de Communications Mining (IXP) de la région des États-Unis ont connu des défaillances de demande intermittentes. L'incident a été limité à l'une des unités de déploiement de la région, où les utilisateurs sur elle ont vu des pannes en rafales de cinq à dix minutes, avec jusqu'à 5 à 7 % de leurs demandes en échec avec 5xx erreurs au pic. Entre les éclatements, le service fonctionnait normalement, les demandes rejugées réussissaient généralement, et aucune donnée n'était perdue. La cause profonde Une tempête de demandes à une fonctionnalité d'API rarement utilisée qui calcule les prévisions d'apprentissage automatique à la demande a coïncidé avec une reconversion répétée du modèle demandé. Chaque recyclage a invalidé les prédictions en cache, transformant chaque demande en un calcul de plusieurs minutes. L'API n'a pas limité le temps d'attente d'une demande pour ce calcul, de sorte que ces demandes de longue durée ont progressivement occupé toutes les capacités de traitement des demandes, ce qui a entraîné l'échec de demandes sans rapport avec elles. L'échelle automatique a atteint sa capacité maximale rapidement et n'a pas pu compenser. Détection La surveillance automatisée a permis de détecter les défaillances à 15 h 15 UTC, environ cinq minutes après le début de l'impact, et a téléphoné à l'ingénieur de garde. L'incident n'a d'abord été attribué qu'au client qui a provoqué l'orage de la demande, mais les rapports des clients et les enquêtes plus poussées ont montré qu'un plus grand nombre d'utilisateurs ont été touchés pendant les ruptures. Réponse L'ingénieur sur appel a tracé les échecs à l'attente sans limite dans le chemin de prédiction sur demande. La capacité de service a été rétablie à plusieurs reprises par remplacement automatique d'instances pendant qu'une correction de code a été mise au point. La correction est un délai strict sur la demande de contribution, donc elle échoue rapidement sans affecter d'autres demandes, et a été déployée dans la région touchée à environ 18h00 UTC, et la résolution a été confirmée à 18h15 UTC. Suivi 1. Le délai strict d'arrêt et la fixation de la charge ont été rendus permanents et ont été libérés dans toutes les régions (achevés le 13 août 2026). 2. Évaluer les limites par client sur le calcul de prédiction sur demande afin que l'utilisation d'un seul client ne puisse pas dégrader l'API partagée.

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

1. 10 août 2026 à 14:11 UTCinvestigating

   Nous enquêtons sur la dégradation des performances des services de première ligne dans la compréhension des documents dans la région de GXP East US. Impact: Les utilisateurs peuvent remarquer des délais d'accès à l'interface utilisateur dans GXP US. Prochaine mise à jour : Des mises à jour supplémentaires seront fournies à mesure que de plus amples renseignements seront disponibles.

2. 10 août 2026 à 14:25 UTCresolved

   Le problème a été résolu et la performance du service de première ligne dans la compréhension des documents est revenue aux niveaux prévus après que la performance dégradée a eu une incidence sur l'interface utilisateur dans la région de GXP Est des États-Unis. Impact: Aucun impact utilisateur en cours.

3. 19 août 2026 à 06:14 UTCpostmortem

   ## Impact client Entre le 10 août 2026 à 13:21 UTC et le 10 août 2026 à 14:03 UTC, un sous-ensemble de clients ont connu des performances dégradées et des délais d'attente lors de l'accès à l'interface utilisateur Document Understanding, qui fournit l'expérience de conception-temps, dans la région des États-Unis retardés. L'automatisation du traitement des documents n'a pas été affectée. Cause profonde Au cours d'un déploiement manuel d'une construction préexistante du service derrière l'interface utilisateur Document Understanding vers la région américaine Retardée, notre processus de déploiement a réaffecté l'identificateur de version du service déployé. L'interface de compréhension des documents exige que ses ressources soient disponibles sous le même identifiant de version que le service déployé. Comme le processus de déploiement a changé cet identifiant, l'interface n'a pas pu localiser les ressources requises, ce qui l'a rendu inaccessible ou périmé. Détection Nous avons pris connaissance de la question quelques instants après la fin du déploiement, grâce à une vérification manuelle dans le cadre de la liste de contrôle du déploiement manuel. Une alerte automatisée a suivi, déclenchée à 13h28 UTC le 10 août 2026. Réponse Après avoir identifié la raison de l'échec du déploiement manuel, notre équipe d'ingénieurs a commencé à déployer une mise à jour corrigée avec les ressources nécessaires disponibles. Dans le même temps, l'équipe des opérations a été engagée pour effectuer un renversement manuel du déploiement. Le retour a été effectué à 14h03 UTC, ce qui a permis de rétablir l'accès à l'expérience de conception-temps. À 14h11 UTC, nous avons publié une mise à jour publique indiquant les performances dégradées et les délais possibles dans l'interface utilisateur de Document Understanding pour la région des États-Unis en retard. À 14h15 UTC, la mise à jour corrigée était terminée et l'interface a été confirmée comme étant déployée avec une nouvelle version correcte et fonctionnant. À 14 h 25 UTC, l'incident a été marqué et la page publique sur le statut a été mise à jour pour confirmer que la performance de l'interface de la compréhension des documents était revenue aux niveaux prévus. Suivi 1. Nous réduisons le temps nécessaire pour restaurer une version antérieure du service, de sorte que la récupération d'un déploiement échoué est plus rapide. 2. Nous apportons des améliorations au processus de déploiement manuel afin de prévenir une situation future, en validant l'existence des ressources nécessaires comme condition préalable.

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

1. 8 août 2026 à 11:54 UTCidentified

   Nous avons identifié la cause de la panne d'Uipath Apps est en panne dans la région des États-Unis retardés et travaillent sur une solution. Impact : Les utilisateurs peuvent continuer d'être incapables d'accéder aux applications et solutions Uipath dépendant des applications Uipath. L'équipe travaille sur la restauration du service.

2. 8 août 2026 à 13:01 UTCidentified

   Team is working on service restoration. We will update the status once mitigation is completed.

3. 8 août 2026 à 14:14 UTCidentified

   Team has identified an issue with an underlying resource and is actively working to restore service.

4. 8 août 2026 à 15:30 UTCidentified

   Team has made progress to fix underlying resource issue and is actively working to restore service.

5. 8 août 2026 à 15:32 UTCmonitoring

   Mitigation has been applied and performance is improving for the issue. We are monitoring closely to ensure stability.

6. 8 août 2026 à 16:01 UTCresolved

   The mitigation has remained stable, and performance has returned to expected levels. We have confirmed service restoration for UiPath Apps in the Delayed US region and are marking this incident as resolved.

7. 12 août 2026 à 10:14 UTCpostmortem

   ## Customer impact Between 11:20 am UTC and 2:54 pm UTC on August 8, 2026, a subset of customers in the Delayed US region experienced failures accessing UiPath Apps and solutions that depend on UiPath Apps. Customers may have seen UiPath Apps unavailable or intermittent request failures. The impact lasted approximately 3 hours and 34 minutes. ## Root cause The incident was caused by database connection saturation following scheduled maintenance performed by our database provider. As application services scaled up, they created additional database connections, which caused new connection attempts to fail and resulted in connection reset errors in UiPath Apps. ## Detection Automated alerts detected the issue at 11:24 am UTC on August 8, 2026. Application telemetry showed failures beginning at approximately 11:20 am UTC. ## Response At 11:00 am UTC, scheduled maintenance began automatically. At 11:20 am UTC, requests began failing. At 11:24 am UTC, automated alerts were triggered, and the team began investigating. At 12:24 pm UTC, database capacity was scaled up as a mitigation. At 1:13 pm UTC, application services were restarted to reduce saturated connection usage and refresh database connections. Connection levels remained elevated, and the database automatically scaled at 1:22 pm UTC and at 2:36 pm UTC. Following these mitigation efforts, request failures stopped at 2:54 pm UTC. At 3:33 pm UTC, the mitigation was confirmed to be stable, and performance was improving. Full recovery was confirmed at 4:01 pm UTC after performance returned to expected levels. ## Follow up 1. Obtain and review the database provider's root cause analysis explaining what caused the connection issue following their maintenance activity. 2. Implement an application-side limit on database connection creation to prevent connection saturation. 3. We are reviewing the automatic scaling behavior that amplified connection volume during the incident and address any contributing factors.

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

1. 6 août 2026 à 21:14 UTCresolved

   Entre 06-08-2026 10:00 UTC et 06-08-2026 13:00 UTC, certaines organisations de la région des États-Unis n'ont pas été en mesure de compléter l'ingestion de documents. Un petit nombre de demandes de recherche dans la même région ont également été lentes ou reportées. La question a été causée par une contrainte de capacité affectant le traitement par ingestion aux États-Unis. La performance normale a été rétablie à 13h00 UTC. Nous avons surveillé les milieux touchés depuis le rétablissement et nous avons confirmé que le problème était entièrement atténué. Les demandes d'ingestion qui ont échoué pendant cette fenêtre n'ont pas été réévaluées automatiquement et devront être soumises à nouveau. Aucune action n'est nécessaire pour la recherche.

2. 13 août 2026 à 15:12 UTCpostmortem

   ## Customer impact Between August 6, 2026 at 10:00 am UTC and 1:00 pm UTC, some organizations in the US region were unable to complete document ingestion in **UiPath Context Grounding**. A small number of search requests in the same region were also slow or timed out. **Action required:** please re-submit the affected ingestion requests. Ingestion retries a failing request automatically for a limited number of attempts. Once those attempts are exhausted the request is marked failed and is not retried again, so affected documents will not appear in your index until the request is submitted again. Failed requests are listed in the ingestion history for each index. No action is required for search. Those requests were affected only while the issue was ongoing, and subsequent searches completed normally. --- ## Root cause A sudden increase in concurrent document ingestion triggered a high number of simultaneous document validation steps, which created a capacity bottleneck on the underlying infrastructure resource beyond its scaling capacity. Once that resource was saturated, ingestion operations began exceeding their time limits and failing. Automatic retries of the failed operations added further load, which sustained the condition. Search requests served by the same resource were delayed behind the same contention. --- ## Detection Automated alerts were flagged as the condition developed, and an automated infrastructure resource capacity alert triggered at 10:37 am UTC brought it to the team's attention. --- ## Response - **10:03 am UTC** — Automated low severity alerts started coming in. - **10:37 am UTC** — Automated alert for resource capacity issue paged the team. - **12:23 pm UTC** — As a mitigation step the impacted resource's capacity was increased. - **12:57 pm UTC** — Ingestion and search operations stopped failing and response times returned to normal. --- ## Follow-up - **The fix is deployed.** The validation step has been reimplemented to enforce the same limits at a small fraction of the previous cost, so this level of concurrent ingestion now sits well within available capacity. It was released to the affected US region on August 7, ahead of schedule, and reaches all remaining regions by early September. - **We are improving how quickly we detect issues like this.** We are adding monitoring that tracks whether document ingestion is completing successfully for customers, so problems are identified and acted on directly rather than inferred from underlying system alerts. This will be in place across all regions by the end of August.

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