Histórico de interrupções do Uipath

1. 28 Here 2026 da 10:04 UTCinvestigating

   Estamos a investigar o aumento da latência e os atrasos na execução do trabalho no âmbito do serviço de orquestradores na região da Europa. Nossa equipe está trabalhando ativamente para identificar a causa raiz e fornecerá atualizações adicionais à medida que mais informações ficam disponíveis.

2. 28 Here 2026 da 10:28 UTCmonitoring

   A questão foi atenuada e estamos a acompanhar o serviço para garantir a estabilidade.

Traduzido automaticamente da atualização oficial do incidente.

1. 27 Here 2026 da 16:39 UTCresolved

   Em 27 de outubro de 2026, entre 14:35 e 16:08 UTC, a compreensão do documento na região da Europa experimentou uma parada parcial que afetou extração generativa, classificação generativa e autovalidação. A causa raiz era um problema de conectividade com um provedor de armazenamento de terceiros. A conectividade foi restaurada e confirmamos que a extração e classificação funcionam normalmente desde 16:08 UTC.

Traduzido automaticamente da atualização oficial do incidente.

1. 26 Here 2026 da 14:04 UTCidentified

   Atualmente estamos investigando um problema que afeta a disponibilidade de insights e serviços de automação. Nossa equipe está ativamente avaliando a situação para identificar a causa subjacente e determinar os passos necessários para restaurar as operações normais. Serão fornecidas mais actualizações à medida que mais informações estiverem disponíveis.

2. 26 Here 2026 da 15:35 UTCidentified

   O problema com a Automation Ops foi resolvido. Estamos atualmente à espera que a questão do serviço Insights seja atenuada. Outras atualizações serão compartilhadas à medida que estiverem disponíveis.

3. 26 Here 2026 da 17:09 UTCidentified

   Serviço Insights em Cingapura, Japão, Suíça, Canadá, Índia, Reino Unido, Europa, Estados Unidos, Emirados Árabes Unidos, Coreia do Sul e Austrália região é fixa e estamos aplicando fixar em outras regiões

4. 26 Here 2026 da 18:27 UTCresolved

   A questão foi resolvida, e todos os serviços estão agora a funcionar normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 27 Here 2026 da 10:13 UTCresolved

   Em 26 de outubro de 2026, entre 10:20 e 17:30 UTC, Automation Cloud Robots (VM) experimentou uma falha parcial afetando as operações da máquina. Durante essa janela, ações como iniciar, parar ou fornecer máquinas VM podem não ter sido concluídas, e trabalhos programados nessas máquinas podem ter sido atrasados ou defeituosos. A causa foi uma configuração incorreta de permissões em um subconjunto dos recursos de infraestrutura subjacentes. Nossa equipe identificou o problema, corrigiu a configuração e confirmou que as operações da máquina funcionam normalmente desde 17:30 UTC. Estamos revisando como a configuração errada foi introduzida e estamos adicionando verificações para evitar uma recorrência. Nenhuma ação é necessária do seu lado. Se você ainda vir tarefas falhadas ou presas a partir dessa janela, por favor, tente novamente e contate suporte se o problema persistir.

Traduzido automaticamente da atualização oficial do incidente.

1. 23 Here 2026 da 21:35 UTCresolved

   Entre 20:42 e 21:19 UTC em 23 de outubro, alguns clientes da Orchestrator na Europa viram respostas lentas e erros intermitentes. Isso incluiu chamadas de robô para obter ativos, processar itens de fila e relatar status de trabalho. Alguns trabalhos não assistidos podem ter falhado durante este tempo. A causa foi um aumento súbito da carga que atingiu os limites de recursos da base de dados. Adicionamos capacidade de banco de dados, e o desempenho voltou ao normal desde 21:19 UTC. Os clientes cujos trabalhos falharam nesta janela poderão ter de os reiniciar.

Traduzido automaticamente da atualização oficial do incidente.

1. 22 Here 2026 da 12:59 UTCinvestigating

   Identificamos um problema que afeta o IXP para clientes hospedados na região da Austrália. Desde 10:24 UTC, solicitações que usam o modelo Gemini 2.5 Flash estão falhando na região. Outros modelos não são afetados. Os dados dos clientes continuam a ser processados apenas na Austrália. Estamos trabalhando com o Google para restaurar o serviço

2. 22 Here 2026 da 14:19 UTCmonitoring

   Um reparo foi implantado e o serviço está se recuperando. Estamos monitorando o sistema para garantir a recuperação total. Mais atualizações serão compartilhadas em breve

3. 22 Here 2026 da 14:33 UTCinvestigating

   Após a recuperação inicial, o serviço degrada-se novamente. Estamos a investigar e a trabalhar no sentido de uma resolução. Nós forneceremos atualizações adicionais à medida que elas se tornam disponíveis.

4. 22 Here 2026 da 15:42 UTCinvestigating

   Contactámos o Google Support e eles começaram a investigar. Continuaremos a monitorizar e a partilhar actualizações.

5. 22 Here 2026 da 17:56 UTCmonitoring

   Estamos observando melhorias no tráfego Gêmeos 2.5 Flash. Estamos monitorando uma possível correção do Google.

6. 22 Here 2026 da 21:02 UTCresolved

   O problema é resolvido no Google.

7. 26 Here 2026 da 03:20 UTCpostmortem

   # # Impacto do cliente Entre 22 de outubro de 2026 às 10:24 UTC e 22 de outubro de 2026 às 6:04 UTC, pedidos de processamento de documentos que usaram Gemini 2.5 Flash na região da Austrália falhou com erros de capacidade. O impacto durou aproximadamente 7 horas e 40 minutos. Um subconjunto de clientes usando fluxos de trabalho de extração de documentos naquela região foi afetado. Durante uma tentativa de retrocesso temporária na região, alguns pedidos de extração recuperaram brevemente, mas a atribuição de nível de palavra e o texto de página gerado foram degradados até que o retrocesso também começou a falhar. # # Causa raiz A causa raiz foi uma ruptura de rede regional do lado do provedor durante a manutenção concorrente. Isso fez com que a frenagem de largura de banda no ambiente de manutenção de modelos do provedor, o que impediu os sistemas de infraestrutura de carregar os dados do modelo necessários para servir Gemini 2.5 Flash e Gemini 3.5 Flash solicitam de forma confiável na região afetada. # # Detecção O problema foi detectado por meio de alerta automático que identificou erros limitantes de taxa em Gemini 2.5 Flash na região da Austrália. Nossa equipe de engenharia confirmou por telemetria que as solicitações afetadas estavam falhando consistentemente e começou a coordenar uma resposta. # # Resposta Às 1:40 pm UTC, nós encaminhamos afetou Gemini 2.5 Flash tráfego para Gemini 3.5 Flash dentro da mesma região para preservar a residência de dados. A telemetria inicial não apresentou erros de capacidade após essa alteração, mas às 2:10 pm UTC, Gemini 3.5 Flash também estava retornando erros de capacidade, então o recuo não era mais viável. Às 2:05 pm UTC, foram ajustados caminhos de processamento de documentos relacionados para que a atribuição e a geração de texto-página utilizassem o mesmo retrocesso na região; esse ajuste foi completado em aproximadamente 2:09 pm UTC. Após o retorno também falhou, revertemos a mudança de roteamento, e às 4:28 pm tráfego UTC estava de volta no caminho esperado Gemini 2.5 Flash. Às 17h38 UTC, a telemetria mostrou melhora nas taxas de sucesso de Gêmeos 2.5 Flash. A partir das 6h04 UTC, não foram observados mais erros de capacidade, e as solicitações subsequentes foram bem-sucedidas. # # Acompanhamento 1. Completar a avaliação de capacidade do modelo reservado para a região afetada utilizando os padrões de tráfego observados 2. Avaliar o comportamento de retry e backoff em clientes de processamento de documentos para reduzir a amplificação de retry durante falhas de capacidade do lado do provedor.

Traduzido automaticamente da atualização oficial do incidente.

1. 15 Here 2026 da 12:27 UTCinvestigating

   Desde aproximadamente 11:17 UTC, clientes em várias regiões têm tido problemas com a UiPath Agents e Solutions Management. Novos trabalhos podem permanecer em status pendente, e os agentes em execução podem sofrer atrasos no processamento de escalas ou à espera de resultados de ferramentas. Estamos investigando a questão e trabalhando para uma resolução.

2. 15 Here 2026 da 13:04 UTCmonitoring

   A questão foi atenuada. Estamos a monitorizar os serviços afectados em todas as regiões para garantir a estabilidade e confirmar que as implantações de postos de trabalho e soluções funcionam normalmente.

3. 15 Here 2026 da 13:22 UTCresolved

   Este incidente foi resolvido. Entre 11:15 e 12:45 UTC em 15 de outubro, uma questão de configuração interna impediu alguns eventos de serem entregues entre serviços UiPath em várias regiões. A questão foi resolvida com o retrocesso da mudança, e a nova atividade está sendo processada normalmente. Alguns trabalhos iniciados ou em andamento durante esta janela podem requerer atenção: - Agentes: Agentes à espera de tarefas do Centro de Ação ou resultados de ferramentas de automação podem permanecer presos. Jobs iniciados do Orchestrator também podem aparecer presos ou fora do tempo. - Maestro: Processos à espera de tarefas do usuário podem não ter retomado após a conclusão da tarefa. - Apps: Os status dos itens em fila podem estar desatualizados, e as ações desencadeadas pelo preenchimento do item da fila podem não ter sido executadas. - Piloto automático para todos: Conversas à espera de resultados de automação podem permanecer paradas. - Compreensão do Documento e Contexto Fundamentação: Automaçãos e agentes à espera de extração, validação ou indexação podem permanecer suspensos. - Serviço de Integração: Os eventos do conector podem não ter desencadeado os processos ou notificações esperados. - Soluções e Studio Web: A solução instala, desinstala, publica, implementações e validações iniciadas durante esta janela podem ter falhado ou expirado o tempo. Repetir estas operações pode resolver o problema. Pedimos desculpa pela interrupção e agradecemos a vossa paciência.

4. 21 Here 2026 da 06:47 UTCpostmortem

   ** Impacto do cliente Em 15 de outubro de 2026, das 11:15 às 12:50 UTC (cerca de 1 hora e 35 minutos), alguns eventos trocados entre serviços de nuvem UiPath não foram entregues. Clientes em todas as regiões de nuvem comercial foram afetados. Durante esta janela: - Os novos agentes podem ficar em estado pendente. Agentes em execução à espera de um resultado de ferramenta, uma escalada humana, extração de documentos ou aterramento de contexto podem não retomar. - Agentes conversacionais e piloto automático para todas as conversas que iniciaram uma automação podem não ter recebido seu resultado. - As instâncias de processo Maestro à espera de uma tarefa do usuário podem não ter avançado após a tarefa ter sido concluída, e os processos desencadeados por eventos de conexão de serviço de integração podem não ter começado. - Apps mostrando ou reagindo ao status do item da fila podem mostrar informações desatualizadas. - A solução instala, desinstala, publica e implementações podem falhar ou perder tempo. - Algumas mudanças de usuário, grupo e pasta feitas na janela podem não ter se propagado para todos os serviços. O trabalho começou após 12:50 UTC não foi afetado. Execução de trabalho do robô, filas e gatilhos manipulados dentro do Orchestrator continuaram funcionando normalmente. ** Causa da raiz Estávamos movendo a entrega de configuração de serviço interno para um novo mecanismo, uma mudança destinada a não ter nenhum efeito sobre os clientes. Quando esta alteração foi aplicada ao serviço de entrega de eventos, a configuração que produziu estava faltando um valor necessário. Sem ele, o serviço tratou várias integrações de produtos como desligadas e silenciosamente parou de entregar seus eventos. Como a mudança atingiu todas as regiões de produção ao mesmo tempo, todas as regiões foram afetadas. **Detecção** A questão foi detectada às 11:51 UTC, cerca de 35 minutos após o início do impacto, quando o monitoramento foi alertado sobre os trabalhos dos agentes que permanecem em estado pendente. Seguiram-se os relatórios de implantações de soluções e um incidente foi declarado às 12:12 UTC. **Resposta Após a primeira detecção às 11:51 UTC, a mudança de configuração foi identificada e um retorno foi iniciado às 12:00 UTC. Um retorno inicial em 12:14 UTC não restaurar totalmente a entrega. A equipe então parou o novo processo de entrega de configuração e restaurou a configuração anterior. A entrega do evento começou a se recuperar às 12:40 UTC, e a recuperação total em todas as regiões foi confirmada às 12:50 UTC. Sempre que possível, repetimos eventos perdidos para que o trabalho afetado pudesse continuar. ** Seguir ** 1. O novo processo de entrega de configuração foi pausado para o serviço afetado e ficará parado até que a configuração seja gerada corretamente. 2. Validar a configuração produzida pelo novo mecanismo de entrega para os valores necessários antes de ser aplicado a qualquer ambiente. 3. Role mudanças para a entrega de configuração progressivamente em todas as regiões em vez de todas as regiões de uma só vez. 4. Melhore nosso monitoramento para detectar dentro de minutos quando os eventos deixarem de ser entregues a uma integração do produto que normalmente os recebe. 5. Melhorar a nossa capacidade de recuperar e devolver eventos perdidos durante uma interrupção.

Traduzido automaticamente da atualização oficial do incidente.

1. 15 Here 2026 da 12:03 UTCresolved

   Alguns clientes na região dos EUA sofreram atrasos na ingestão de logs de robôs, com aumento da atividade observada entre aproximadamente 11:20 e 11:45 UTC. O problema foi resolvido, e a ingestão de log voltou ao normal. Obrigado pela vossa paciência.

2. 22 Here 2026 da 10:13 UTCpostmortem

   # # Impacto do cliente Entre aproximadamente 15 de outubro de 2026 às 23:20 horas UTC e 15 de outubro de 2026 às 23:45 horas UTC, alguns clientes na região leste dos EUA sofreram atrasos na ingestão de log robô em UiPath Orchestrator. Os logs dos robôs não estavam atualizados durante o período afetado. O impacto durou aproximadamente 20 minutos. # # Causa raiz Durante o incidente, 2 das 13 instâncias de serviço manipulando a ingestão de log robô foram observadas não se conectando ao serviço de ingestão de eventos. Apenas os pedidos para o serviço de ingestão de eventos estavam falhando, e apenas nessas duas instâncias. Isso fez com que alguns pedidos de ingestão de log robô não completassem com sucesso, resultando em dados de log atrasados para clientes afetados. A causa principal do porquê apenas aquelas duas instâncias perderam conectividade com o serviço de ingestão de eventos não foi determinada durante o incidente. A equipe comprometeu-se a uma revisão pós-incidente dos logs das instâncias afetadas para identificar a causa subjacente. Acreditamos que seja um problema de infraestrutura não relatado pelo nosso provedor de nuvem. # # Detecção A questão foi detectada por meio de um alerta automatizado às 23h33 UTC, em 15 de outubro de 2026, e confirmada por meio de telemetria mostrando exceções das duas instâncias de serviço afetadas. # # Resposta Após a detecção, a telemetria confirmou que apenas duas instâncias de serviço estavam gerando exceções. Os respondedores removeram essas duas instâncias não saudáveis do serviço, e as instâncias de substituição começaram automaticamente. Cerca de 20 minutos após a primeira indicação — cerca de 23:53 UTC —, a telemetria indicava que a recuperação e os controlos de monitorização sintéticos estavam a passar. Um reinício mais amplo de todas as instâncias de serviço foi considerado, mas não realizado, pois a equipe determinou que não deveria prosseguir sem primeiro entender a causa raiz. # # Acompanhamento 1. Uma revisão pós-incidente dos logs das instâncias de serviço afetadas revelou que o problema estava relacionado à infraestrutura, e estamos acompanhando o provedor de infraestrutura na nuvem para mais detalhes. 2. Uma atualização será publicada se o inquérito produzir mais conclusões.

Traduzido automaticamente da atualização oficial do incidente.

1. 14 Here 2026 da 07:26 UTCmonitoring

   A partir das 6:50 UTC, tivemos uma falha global que afetou o carregamento de aplicativos e aplicativos codificados em todas as regiões, exceto Índia e Reino Unido. A deficiência foi resolvida e os serviços estão totalmente operacionais. Impacto: Nenhum impacto contínuo do usuário.

2. 14 Here 2026 da 07:43 UTCresolved

   A partir das 6:50 UTC, tivemos uma falha global que afetou o carregamento de aplicativos e aplicativos codificados em todas as regiões, exceto Índia e Reino Unido. A deficiência foi resolvida e os serviços estão totalmente operacionais. Impacto: Nenhum impacto contínuo do usuário.

3. 23 Here 2026 da 12:08 UTCpostmortem

   # # Impacto do cliente Entre 06:38 UTC e 07:21 UTC em 14 de outubro de 2026, uma parte dos pedidos para UiPath Apps, aplicativos codificados e soluções que dependem deles falhou em onze regiões: Europa, Estados Unidos, Comunidade, Japão, Cingapura, Austrália, Canadá, Coreia do Sul, Suíça, Emirados Árabes Unidos e o ambiente atrasado dos EUA. As regiões da Índia e do Reino Unido não foram afectadas. Cerca de 2% das solicitações falharam no geral, entre 0,6 e 5% dependendo da região. Usuários afetados viram aplicativos falharem em carregar, requisições retornarem erros de servidor ou respostas lentas. Em regiões onde pods de serviço tiveram que ser reiniciados, Apps foi inacessível por cerca de oito minutos. Os tempos de resposta voltaram ao normal em todas as regiões às 07:40 UTC. A maioria dos usuários de aplicativos já em execução publicados notaram pouco ou nada. As definições do aplicativo são armazenadas em cache no navegador por até 24 horas, os dados do aplicativo vêm do Data Service e do Orchestrator em vez deste banco de dados, e o serviço continuou usando as conexões do banco de dados que ele já realizou. As solicitações que falharam foram aquelas que precisavam de uma nova conexão com o banco de dados: abrir o designer ou a lista de aplicativos, carregar um aplicativo ainda não armazenado, baixar documentos e imagens armazenados em Apps e salvar ou publicar. # # Causa raiz Às 06:38 UTC, enquanto o acesso ao banco de dados estava sendo configurado para uma nova implantação regional, a senha do usuário do banco de dados que o serviço Apps usa foi alterada. Esse usuário é compartilhado pelos clusters de base de dados de produção de todas as regiões afetadas, de modo que a mudança aplicada a todas elas ao mesmo tempo. Os serviços em execução ainda tinham a senha anterior e não podiam mais abrir novas conexões de banco de dados. As regiões da Índia e do Reino Unido não utilizam esta credencial e não foram afectadas. A mudança foi feita para criar um usuário de banco de dados separado para a nova região. Em vez disso, a senha do usuário existente que todas as regiões compartilham foi alterada. Nosso processo de mudança para credenciais de banco de dados não se separou claramente criar uma nova credencial de modificar uma existente, e não exigiu uma verificação de quantos clusters e regiões uma mudança credencial afetaria. Combinado com um único usuário de banco de dados sendo compartilhado entre regiões, isso permitiu uma mudança destinada a uma região para causar uma parada multi-região. # # Detecção Nosso monitoramento interno levantou o primeiro alerta às 06:41 UTC, três minutos após as primeiras falhas, e alertas para todas as regiões afetadas seguidas pelas 06:46 UTC. Às 06:50 UTC, o engenheiro de plantão confirmou que cada cluster de produção estava sendo recusado por seu banco de dados e iniciou o processo de incidente. # # Resposta Às 07:05 UTC a senha anterior foi restaurada e falhas de autenticação pararam em todos os lugares. A maioria das regiões reconectou-se automaticamente. Nas regiões que não o fizeram, as cápsulas de serviço foram reiniciadas ou reinstaladas: EUA atrasados às 07:21 UTC e Suíça às 07:30 UTC. Falhas de solicitação pararam às 07:21 UTC, os tempos de resposta voltaram à linha de base às 07:40 UTC, e continuamos monitorando até que o incidente foi resolvido às 07:43 UTC. # # Acompanhamento Para evitar que isto volte a acontecer, somos: - Introdução de um procedimento definido para a criação e rotação de credenciais de banco de dados, com uma revisão pré-mudança que indica quais clusters e regiões compartilham a credencial, e uma implantação encenada que é verificada em uma região antes de ser aplicada mais amplamente. - Passando para usuários de banco de dados separados, menos privilegiados para cada região, de modo que uma mudança em uma região não pode afetar outra. - Declarar automaticamente um incidente e chamar os proprietários da base de dados quando o mesmo erro de base de dados é detectado em várias regiões ao mesmo tempo, em vez de confiar na escalada manual de alertas regionais individuais. - Habilitando serviços para pegar credenciais atualizadas do banco de dados sem reiniciar e reconectar mais rápido após uma falha de autenticação.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Here 2026 da 14:03 UTCinvestigating

   Atualmente estamos investigando uma falha que afeta os serviços da UiPath Cloud em várias regiões. Os utilizadores não podem aceder aos serviços hospedados nas regiões afectadas. Próxima atualização: Informações adicionais serão compartilhadas à medida que estiverem disponíveis.

2. 13 Here 2026 da 14:37 UTCinvestigating

   Continuamos a investigar esta questão.

3. 13 Here 2026 da 14:42 UTCinvestigating

   Foi implementada uma correção e estamos monitorando os resultados. A questão foi limitada ao Compreensão de Documentos, Visão de Computador, Proxy Semântico, Autopilot Studi, IXP. Vamos compartilhar outra atualização uma vez que os serviços tenham recuperado totalmente.

4. 13 Here 2026 da 15:10 UTCinvestigating

   Foi implementada uma correção e estamos monitorando os resultados.

5. 13 Here 2026 da 15:19 UTCresolved

   Este incidente foi resolvido após a renovação do certificado SSL expirado que afetou vários serviços ML-dependentes, incluindo IXP, Document Understanding, Computer Vision, Semântico Proxy e Autopilot para desenvolvedores. A recuperação do serviço progrediu em todas as regiões afetadas, e alertas automatizados foram configurados para ajudar a detectar a expiração do certificado com antecedência e evitar perturbações semelhantes no futuro. Obrigado pela vossa paciência e compreensão.

6. 26 Here 2026 da 03:17 UTCpostmortem

   # # Impacto do Cliente Entre 13:37 e 14:40 UTC em 13 de outubro de 2026, os clientes de várias regiões não puderam usar documentos não estruturados IXP, IXP Communications Mining e Document Understanding. Computer Vision e Autopilot para desenvolvedores recursos que dependem dos mesmos serviços de aprendizado de máquina também falhou. Os clientes afetados viram solicitações falharem com as respostas de "500 Erro Interno do Servidor" ou o tempo fora, projetos IXP que não abririam e atividades de Visão de Computador falhando na execução de automações. O serviço foi interrompido por aproximadamente 1 hora. Nenhum dado do cliente foi perdido. # # Causa raiz O incidente foi causado por um certificado de segurança expirado usado para estabelecer conexões seguras com esses serviços. O certificado é renovado por um processo automatizado. Esse processo não foi mais executado com sucesso e as falhas não levantaram um alerta, então o certificado não foi substituído antes de expirar. As ligações seguras aos serviços afectados foram rejeitadas a partir das 13:37 UTC. # # Detecção O monitoramento automatizado começou a alertar sobre erros e falta de tráfego às 13:40 UTC, e o incidente foi declarado às 13:54 UTC. O certificado expirado foi identificado às 14:00 UTC, e a primeira atualização da página de status foi postada às 14:03 UTC. Nenhum alerta alertou que o certificado estava se aproximando da expiração, e as falhas repetidas da renovação automatizada não foram relatadas à equipe proprietária, então o problema só foi detectado quando os clientes foram afetados. # # Resposta Às 14:06 UTC a equipe confirmou que o certificado tinha expirado porque a renovação automática tinha falhado. Às 14:18 UTC uma nova credencial foi emitida para o processo de renovação. A renovação foi iniciada manualmente às 14:19 UTC e concluída às 14:33 UTC, e às 14:37 UTC todos os parâmetros de avaliação virados para o cliente tinham sido verificados para servir o certificado renovado. O trânsito voltou aos níveis normais em aproximadamente 14:40 UTC. Após um período de monitoramento, o incidente foi resolvido às 15:19 UTC. # # Acompanhamento Para ajudar a prevenir incidentes semelhantes no futuro, estamos fazendo as seguintes melhorias: - Alerte com antecedência qualquer um destes certificados que se aproxime da expiração. - Notificar a equipa proprietária sempre que a renovação automática falhar. - Adicione verificações de alerta assim que as ligações seguras a estes serviços falharem. - Reforçar a propriedade do processo de renovação do certificado e as credenciais em que se baseia.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Here 2026 da 10:32 UTCinvestigating

   Estamos a investigar o problema onde os registos de execução de robôs não aparecem no Orchestrator. estamos trabalhando para determinar o escopo completo e a causa raiz.

2. 13 Here 2026 da 10:57 UTCresolved

   Esta questão foi resolvida. Registros de execução de robôs estão sincronizando e são visíveis no Orchestrator novamente para Japan Orchestrator. Obrigado pela vossa paciência.

3. 22 Here 2026 da 13:25 UTCpostmortem

   # # Impacto do cliente Entre aproximadamente 07:00 UTC em 9 de outubro de 2026 e 10:45 UTC em 13 de outubro de 2026, cerca de 6% das entradas de log robô para clientes na região do Japão não apareceu em Orchestrator. A execução do trabalho e todas as outras funcionalidades do Orchestrator não foram afetadas. Entradas desaparecidas tornaram-se visíveis no Orchestrator após o problema ser corrigido. # # Causa raiz Os logs de robôs são colocados em uma fila dividida em 32 partições, e um serviço de ingestão lê cada partição e armazena os logs para o Orchestrator. Em 9 de outubro, o serviço de ingestão na região do Japão parou de ler a partir de 2 das 32 partições sem relatar um erro. Os logs dessas partições foram mantidos na fila, mas não armazenados, então eles não apareceram no Orchestrator. Nosso monitoramento verificou o serviço como um todo, não cada partição, então o problema não foi detectado automaticamente. # # Detecção O problema foi detectado através de relatórios de clientes. Declaramos um incidente às 10:13 UTC em 13 de outubro e postamos uma notificação de página de status às 10:32 UTC. # # Resposta Reiniciamos o serviço de ingestão em aproximadamente 10:41 UTC, e ele retomou a leitura de todas as partições. Os logs mantidos na fila foram então processados e ficaram visíveis no Orchestrator. O incidente foi resolvido às 10:57 UTC. # # Acompanhamento * Estamos adicionando monitoramento que nos alerta quando qualquer partição deixa de ser lida, então esse tipo de problema é detectado em minutos.

Traduzido automaticamente da atualização oficial do incidente.

1. 7 Here 2026 da 21:34 UTCinvestigating

   Estamos investigando relatórios de uma falha impactando a criação de tarefas HITL para Maestro nos EUA. Impacto: Os usuários podem não ser capazes de criar tarefas HITL. Próxima atualização: Nossas equipes estão trabalhando para entender a causa e escopo e compartilharão atualizações conforme disponíveis.

2. 8 Here 2026 da 01:30 UTCidentified

   Identificou-se a causa de uma falha impactando a criação de tarefas HITL para Maestro nos EUA e estão trabalhando para mitigar a questão. Impacto: Os usuários podem não ser capazes de criar tarefas HITL. Próxima atualização: Nossas equipes estão trabalhando para mitigar o problema e compartilharão atualizações conforme disponível.

3. 8 Here 2026 da 03:28 UTCmonitoring

   Estamos lançando uma correção para uma falha impactando a criação de tarefas HITL para Maestros com temporizadores de tarefa HITL SLA configurados nos EUA e estão trabalhando para mitigar o problema. Impacto: Os usuários podem não ser capazes de criar tarefas HITL dentro dos Maestros com temporizadores de tarefa HITL SLA configurados. Próxima atualização: Nossas equipes estão trabalhando para mitigar o problema e compartilharão atualizações conforme disponível.

4. 8 Here 2026 da 04:29 UTCresolved

   A correção para o problema impactando a criação de tarefas HITL para Maestro com temporizadores de tarefa HITL SLA configurados nos EUA foi totalmente lançada. A criação da tarefa HITL voltou ao normal.

5. 26 Here 2026 da 03:16 UTCpostmortem

   # # Impacto do cliente Em 2026-10-05 entre 9,30 PM UTC - 2026-10-07 3,30 AM Os clientes UTC, Maestro BPMN e Case usando nós HITL com um Temporizador de Tarefa configurado viram falhas de suas instâncias de depuração e produção na fase HITL, com 4xx . Cerca de 30 desses casos em todos os clientes dos EUA e da Europa foram identificados, que foram bloqueados sem solução alternativa. # # Causa raiz A configuração de uma tarefa SLA requer um objeto incluindo os critérios de início e fim, o temporizador do SLA e o resultado da violação do SLA. Os clientes configuram isso no designer Maestro no nó HITL. O resultado foi erroneamente mantido não obrigatório na superfície do projeto, embora uma configuração SLA sem um resultado não seja persistente e não faça sentido para os negócios. A equipe de backend do Action Center havia adicionado uma validação para lançar um pedido ruim (400) no caso de um objeto SLA não nulo com um resultado faltando. Isso acabou impactando os clientes que adicionaram os critérios Iniciar/Fim no nó, mas não configuraram um resultado. As instâncias que antes estavam em execução falharam com 400s, e não foram capazes de retomar # # Detecção Um cliente relatou o problema à Maestro Engineering SME, que o levantou internamente com a equipe. A equipe do Maestro investigou esse fracasso, e observou um número crescente de falhas para a USI, e alguns outros inquilinos através de logs, levando-os a envolver a equipe do Action Center. # # Resposta A equipe Maestro recebeu o relatório do problema do cliente via Email, e eles fizeram alguma investigação inicial e identificaram uma possível regressão, seguindo o que, o Centro de Ação PME foi engajado, a questão reproduzida em ambientes inferiores, um retorno do recurso aplicado e testado, e laminado para todas as regiões impactadas. Foi resolvido com todas as instâncias sendo internamente re-experimentado e retomado. # # Acompanhamento 1. Adicione validação para este cenário em todas as superfícies da base de código do serviço cruzado para garantir a revisão humana 2. Adicione testes de monitoramento e integração necessários no local para detectar este problema mais rapidamente

Traduzido automaticamente da atualização oficial do incidente.

1. 7 Here 2026 da 17:37 UTCinvestigating

   Estamos investigando relatórios de lentidão intermitente e erros que afetam um subconjunto de organizações na região leste dos EUA de Automation Cloud. Usuários afetados podem ver páginas na interface do Orchestrator falham em carregar (por exemplo, a página Jobs retornando "Um erro ocorreu"), e operações de robôs como transações de fila e inícios de sessão podem ser intermitentemente interrompidas. Nós forneceremos uma atualização assim que mais informações estiverem disponíveis.

2. 7 Here 2026 da 18:13 UTCmonitoring

   Aplicamos um aumento de capacidade na infraestrutura de banco de dados afetado na região leste dos EUA e as taxas de erro e latência retornaram aos níveis normais. Nós forneceremos uma atualização assim que mais informações estiverem disponíveis.

3. 7 Here 2026 da 19:06 UTCresolved

   Temos a questão na região leste dos EUA e as taxas de erro e latência retornaram aos níveis normais.

4. 14 Here 2026 da 11:42 UTCpostmortem

   # # Impacto do cliente Entre aproximadamente 13:00 UTC e 18:15 UTC em 7 de outubro de 2026, os clientes na região dos EUA experimentaram erros intermitentes e respostas lentas em Orchestrator. Usuários afetados podem ter visto páginas do Orchestrator falharem em carregar, por exemplo, a página Jobs retornando “Ocorreu um erro”, e operações de robôs como transações de fila e inícios de sessão podem ter cronometrado intermitentemente. Outros serviços do UiPath que dependem do Orchestrator também podem ter visto respostas mais lentas ou erros durante esse período. # # Causa raiz Várias operações Orchestrator frequentemente usadas cada uma delas dependiam de um recurso compartilhado de curta duração dentro do banco de dados, incluindo a verificação de status de rotina que cada robô em execução realiza. À medida que o volume de atividade concomitante de robôs nessa região crescia, as solicitações começaram a filar para acessar esse recurso compartilhado em vez de completar seu trabalho. O efeito foi seletivo em vez de um abrandamento geral: as operações que usaram este recurso foram adiadas, enquanto outras continuaram a funcionar normalmente. Como o processador, a memória e o uso do armazenamento do banco de dados permaneceram dentro dos padrões normais, o monitoramento da capacidade de rotina não indicou um problema. # # Detecção Nosso monitoramento automatizado detectou a degradação dentro de aproximadamente 35 minutos do início do impacto do cliente, e nossos engenheiros identificaram a contenção subjacente durante o evento. Por tratar-se de um problema de contenção e não de uma escassez de capacidade, e todos os indicadores de capacidade eram normais, não se esperava que o aumento da capacidade do banco de dados o resolvesse, e a equipe investigou alternativas antes de aplicá-lo. Essa avaliação atrasou a atenuação. # # Resposta Nossa equipe de engenharia aumentou a capacidade do banco de dados afetado. Os tempos de resposta e as taxas de erro retornaram ao normal imediatamente, e continuamos monitorando para confirmar que o serviço estava estável antes de encerrar o incidente. * 13:00 : As taxas de erro e os tempos de resposta começam a aumentar para os clientes na região dos EUA. * 13:36 : Monitoramento automatizado detecta a degradação e notifica a equipe de engenharia de plantão. * 13:36 - 17:29: Engenheiros investigam. Todos os indicadores de capacidade de base de dados normal — processador, memória e armazenamento — permanecem dentro dos intervalos normais ao longo de todo o processo, pelo que a causa não é evidente devido à monitorização de rotina. * 17:29: Um incidente formal é declarado e a equipe de resposta completa está envolvida. 17:38 É publicado um aviso público em [Estado UiPath](http://status.uipath.com/) \(Investigação\). * 17:31 - 17:43 : Capacidade adicional de banco de dados é fornecido para a região afetada. * 18:00 : Taxas de erro, tempos de resposta e latência da solicitação retornam aos níveis normais. * 18:11 : A página de status é atualizada para monitoramento e impacto do cliente termina. * 19:06 : O incidente é encerrado após o monitoramento contínuo confirmar que o serviço é estável. # # Acompanhamento Para evitar que isto volte a acontecer, somos: * Mudando as operações afetadas para que eles não mais dependem do recurso compartilhado. Isto foi aplicado a todos os sistemas afectados e reduziu substancialmente a condição que causou o incidente. * Habilitando o monitoramento detalhado do banco de dados nesses sistemas, então esta classe de contenção é visível enquanto isso está acontecendo ao invés de depois. * Melhorar o nosso alerta para que uma verdadeira degradação deste tipo seja claramente distinguível de variações rotineiras, autocorrectivas, e seja intensificada mais rapidamente.

Traduzido automaticamente da atualização oficial do incidente.

1. 6 Here 2026 da 17:50 UTCinvestigating

   Estamos a investigar relatos de uma avaria que impacta [funcionalidade ou sintoma de utilizador impactado] para o Orquestrador na Europa. Impacto: Os usuários podem esperar atrasos para a ingestão de logs de robôs e/ou pesquisa/exibição dos logs. Nenhum registro será perdido. Próxima atualização: Nossas equipes estão trabalhando para entender a causa e escopo e compartilharão atualizações conforme disponíveis.

2. 6 Here 2026 da 18:28 UTCidentified

   Identificámos a causa de uma interrupção que afectou a ingestão de toros robotizados para o Orchestrator na Europa. Impacto: Os usuários podem esperar atrasos para a ingestão de logs de robôs e/ou pesquisa/exibição dos logs. Nenhum registro será perdido. Próxima atualização: Nossas equipes estão trabalhando para entender a causa e escopo e compartilharão atualizações conforme disponíveis.

3. 6 Here 2026 da 18:43 UTCmonitoring

   Mitigámos o problema da ingestão de toros robotizados para o Orchestrator na Europa. Impacto: Os usuários podem esperar atrasos para a ingestão de logs de robôs e/ou pesquisa/exibição dos logs. Nenhum registro será perdido. Próxima atualização: Nossas equipes estão trabalhando para entender a causa e escopo e compartilharão atualizações conforme disponíveis.

4. 6 Here 2026 da 18:44 UTCresolved

   Mitigámos o problema da ingestão de toros robotizados para o Orchestrator na Europa. Impacto: Os usuários podem esperar atrasos para a ingestão de logs de robôs e/ou pesquisa/exibição dos logs. Nenhum registro será perdido. Próxima atualização: Nossas equipes estão trabalhando para entender a causa e escopo e compartilharão atualizações conforme disponíveis.

5. 7 Here 2026 da 11:08 UTCpostmortem

   # # Impacto do cliente Em , entre 15:45 UTC e 18:45 UTC, os clientes hospedados nas regiões da Europa, Austrália e Japão não puderam ver registros de robôs recentes em Orchestrator. Logs escritos durante a janela de impacto não apareceram nas visualizações Jobs and Logs ou através da API Robot Logs, e logs mais velhos que aproximadamente 03:00 UTC naquele dia estavam disponíveis apenas intermitentemente. A janela de impacto diferiu por região: - Austrália: aproximadamente 15:45 UTC às 18:35 UTC - Europa: aproximadamente 16:35 UTC às 18:00 UTC - Japão: aproximadamente 16:45 UTC às 18:30 UTC A execução de tarefas, filas, gatilhos e todas as outras funcionalidades do Orchestrator não foram afetadas. Nenhum tronco de robô foi perdido. Os logs produzidos durante a janela de impacto continuaram a ser coletados e tornaram-se visíveis novamente uma vez que o problema foi atenuado. # # Causa raiz Estávamos realizando uma atualização programada do serviço Elasticsearch que armazena registros de robôs Orchestrator. A atualização usa uma abordagem azul/verde: um novo cluster é criado ao lado do existente, os dados são restaurados a partir de um backup, o pipeline que ingere novos logs é iniciado nele, e só então o tráfego é trocado. Nas regiões afetadas, o interruptor de tráfego foi aprovado pelo engenheiro que executou a atualização antes da restauração dos dados e o catch-up de ingestão tinha terminado, o que é um desvio do nosso procedimento de atualização. Isto foi um erro humano. Como resultado, o Orchestrator estava lendo logs de robôs de um cluster que ainda não continha dados recentes, enquanto novos logs continuaram a ser coletados, mas ainda não foram indexados nas solicitações de serviço do cluster. O erro não foi detectado porque nossa ferramenta de implantação depende do operador para verificar a completude dos dados e não impõe a ordem entre a restauração dos dados e o interruptor de tráfego. # # Detecção Nosso monitoramento sintético, que executa continuamente trabalhos de teste e verifica que seus registros são devolvidos, detectou registros ausentes nas regiões afetadas e levantou alertas. Nossa equipe de engenharia correlacionou os alertas com a atualização em andamento, declarou um incidente e publicou uma notificação de página de status. # # Resposta Nossa equipe de engenharia reverteu o tráfego para os clusters Elasticsearch anteriores em todas as três regiões, que imediatamente restaurou o acesso a todos os logs de robôs, incluindo os produzidos durante a janela de impacto. Confirmamos a recuperação por meio de monitoramento sintético em todas as regiões afetadas e o monitoramento contínuo antes de marcar o incidente resolvido em aproximadamente 18:45 UTC. A atualização dos novos clusters continua em segundo plano. O tráfego só será transferido para eles depois que a restauração dos dados estiver completa e a ingestão for confirmada como atualizada. # # Acompanhamento Para evitar que isto volte a acontecer, somos: - Alterar o oleoduto de implantação para que o interruptor de tráfego não possa ser executado até que a restauração de dados e a ingestão de log no novo cluster sejam verificadas como completas. - Adicionando um passo de retrocesso automatizado ao gasoduto, para que o tráfego possa ser devolvido ao cluster anterior em poucos minutos se um problema for detectado após um interruptor.

Traduzido automaticamente da atualização oficial do incidente.

1. 6 Here 2026 da 12:38 UTCidentified

   Estamos observando desempenho degradado para serviços em Emirados Árabes Unidos

2. 6 Here 2026 da 12:43 UTCinvestigating

   Estamos actualmente a investigar esta questão.

3. 6 Here 2026 da 14:01 UTCidentified

   Identificamos o problema como um problema de roteamento de rede com um provedor de serviços de terceiros, afetando a conectividade para nossos serviços hospedados nos Emirados Árabes Unidos. Estamos trabalhando com nosso provedor upstream em resolução e atualizaremos o progresso aqui.

4. 6 Here 2026 da 14:22 UTCidentified

   Continuamos trabalhando em uma solução para esse problema.

5. 6 Here 2026 da 14:51 UTCmonitoring

   Estamos monitorando a conectividade e atualizaremos esta página uma vez confirmada a estabilidade.

6. 6 Here 2026 da 15:09 UTCmonitoring

   Continuamos monitorando quaisquer outros problemas.

7. 6 Here 2026 da 17:09 UTCresolved

   O incidente foi resolvido.

8. 21 Here 2026 da 05:36 UTCpostmortem

   # # Impacto do cliente Entre 12:38 PM UTC e 2:51 PM UTC, um subconjunto de clientes na região dos EAU experimentou falhas ao acessar serviços de nuvem UiPath. O incidente durou aproximadamente 2 horas e 13 minutos. Os serviços afetados incluíam acesso a **cloud.uipath.com**, **account.uipath.com** Serviços hospedados nos Emirados Árabes Unidos. Os clientes podem ter encontrado timeouts, autenticação falhada, redefinir conexões ou erros de servidor. # # Causa raiz A causa principal foi uma falha de roteamento de rede regional em um provedor de infraestrutura de terceiros. Um subconjunto de caminhos de rede de saída da região UAN para redes externas específicas — incluindo a rede de entrega de conteúdo que serve **cloud.uipath.com** e **account.uipath.com** — parou de fornecer tráfego. Novas tentativas de conexão de outbound dos serviços afetados não receberam respostas, fazendo com que as solicitações parassem. Nossa equipe de engenharia excluiu a configuração do serviço UiPath, a política de nível de aplicação e a capacidade de conexão de saída como causas. O fornecedor de infraestrutura reconheceu uma questão conhecida que afeta vários clientes no mesmo caminho de rede. # # Detecção O problema foi detectado por meio de monitoramento automatizado. Por volta das 12:40 pm UTC — cerca de dois minutos após o início da falha — a investigação confirmou que novas conexões dos serviços da região da UNA afetados com os principais terminais do UiPath estavam falhando. # # Resposta Por volta de 1:20 pm UTC, nossa equipe de engenharia confirmou que a falha estava limitada a caminhos específicos de rede de saída, enquanto outros destinos permaneceram alcançáveis. Validação descartou mudanças de roteamento do lado do UiPath, alterações de configuração de entrega de conteúdo, política de nível de aplicação e problemas de capacidade de conexão de saída. Foi aberto um processo de apoio de alta gravidade com o fornecedor de infraestruturas de terceiros. Às 1:50 pm UTC, o provedor reconheceu um problema conhecido que afeta vários clientes. Nossa equipe continuou monitorando a recuperação das vias de rede afetadas e verificando a saúde do serviço à medida que o trânsito retornava. Às 2:51 pm UTC, verificações de recuperação confirmaram que o tráfego de UiPath através dos caminhos de entrega de conteúdo afetados tinha retornado aos níveis normais. Verificações de saúde automatizadas e métricas de serviços confirmaram recuperação, e os Serviços na UAN estavam operacionais. # # Acompanhamento 1. Estamos perseguindo a ação corretiva confirmada pelo provedor de infraestrutura e a análise da causa raiz para a falha de roteamento regional. 2. Estamos revisando dependências de serviço de saída na região afetada para fortalecer a resiliência contra rupturas de rede de terceiros semelhantes.

Traduzido automaticamente da atualização oficial do incidente.

1. 2 Here 2026 da 16:23 UTCinvestigating

   Desde cerca de 15:05 UTC, alguns clientes na região dos EUA podem ver trabalhos que funcionam em Cloud Robots levar mais tempo do que o normal para começar, ou ficar no estado pendente. Empregos em seus próprios robôs não são afetados, e nem outras regiões. Encontramos a causa provável e estamos a trabalhar para restaurar o processamento normal do trabalho. Os trabalhos que já estão em fila de espera não são perdidos e serão processados assim que o problema for resolvido. Publicaremos outra actualização dentro de 60 minutos.

2. 2 Here 2026 da 16:34 UTCmonitoring

   Aplicamos uma correção para o problema que atrasou os trabalhos em Cloud Robots na região dos EUA, e trabalhos estão começando normalmente novamente. Os trabalhos que foram atrasados estão agora a ser processados. Estamos monitorando para garantir que o serviço permaneça estável e publicaremos outra atualização em 60 minutos.

3. 2 Here 2026 da 16:51 UTCmonitoring

   Depois de mais trabalhos sobre o assunto, trabalhos em Cloud Robots na região dos EUA estão começando normalmente. Trabalhos que foram atrasados mais cedo estão sendo processados. Continuamos a monitorar o serviço e publicaremos outra atualização quando o problema estiver resolvido.

4. 2 Here 2026 da 17:03 UTCresolved

   Esta questão foi resolvida. Entre 15:05 e 16:39 UTC, os trabalhos em Cloud Robots na região dos EUA foram lentos para começar ou permanecer no estado Pendente. Empregos têm começado normalmente desde 16:39 UTC, e trabalhos que foram atrasados durante este tempo foram agora processados. Pedimos desculpa pela interrupção.

5. 14 Here 2026 da 14:20 UTCpostmortem

   # # Impacto do cliente De 15:00 a 16:38 UTC em 2026-10-02, os trabalhos da Cloud Robots na região dos EUA levaram mais tempo do que o normal para começar, até 22 minutos no pico em torno de 16:20 UTC. O orquestrador permaneceu disponível, nenhum trabalho foi perdido, nenhuma outra região foi afetada. Um pequeno número de clientes recebeu um erro de limite temporário em novas submissões, enquanto seus trabalhos anteriores estavam esperando. # # Detecção Alertas automáticos disparados às 15:07 UTC, sete minutos após o impacto começar. Verificações na região dos EUA falharam a partir das 15:32 UTC e a resposta do incidente começou. # # Causa raiz Às 14:55 UTC, o fluxo de trabalho de um cliente começou a enviar trabalhos cerca de 20 vezes sua taxa normal. O serviço que admite trabalhos mantém uma contagem de concordância por cliente no banco de dados e atualiza-o sob um bloqueio de banco de dados em cada início e fim de trabalho. A essa taxa a fila de bloqueio para o registro do cliente cresceu até que as atualizações cronometraram. As atualizações de espera ocuparam o conjunto compartilhado de trabalhadores que iniciam empregos para todos os clientes da região, então os empregos de cada cliente aguardavam atrás deles. O mecanismo destinado a isolar a carga de um cliente tornou-se o gargalo. # # Resposta A equipe identificou o caminho de admissão sobrecarregado e a carga de trabalho por trás dele. Uma primeira mudança de configuração às 15:46 UTC alvejou o registro errado e não teve efeito. A mudança correta às 16:10 UTC isentou esse tipo de trabalho do cliente do bloqueio do banco de dados e entrou em vigor em cerca de 16:20 UTC. Os tempos de início caíram de cerca de 13 segundos para menos de um segundo e o atraso de cerca de 5200 trabalhos drenados em 18 minutos. O início do trabalho foi normal às 16:38 UTC. O gatilho do cliente foi desligado com o cliente por volta das 16:40 UTC. # # Acompanhamento O limite de taxa bloqueado pelo banco de dados é substituído por mecanismo de limitação de taxa de desempenho em memória alta, então a carga de um cliente não pode bloquear o trabalho começa para outros. A mudança é completa, testada em pré-produção com a mesma carga, e sendo lançada para fora.

Traduzido automaticamente da atualização oficial do incidente.

1. 2 Here 2026 da 00:13 UTCinvestigating

   Atualmente estamos investigando uma falha que afeta o portal Insights na região dos EAU. Usuários desta região podem não ser capazes de acessar o portal ou podem experimentar cargas de página falhadas. Nossa equipe está trabalhando ativamente para identificar a causa e restaurar o serviço. Forneceremos outra atualização assim que tivermos mais informações.

2. 2 Here 2026 da 00:36 UTCidentified

   Identificamos um caminho de mitigação e estamos iniciando um retrocesso na região dos EAU. Os usuários podem continuar a experimentar problemas de acesso intermitentes com o portal Insights enquanto este trabalho está em andamento. Forneceremos outra atualização assim que o retorno estiver completo.

3. 2 Here 2026 da 00:41 UTCmonitoring

   O portal Insights na região dos Emirados Árabes Unidos está carregando com sucesso após nosso retorno. Continuamos a acompanhar o serviço para confirmar a estabilidade e forneceremos uma atualização final uma vez que estejamos confiantes de que a questão está totalmente resolvida.

4. 2 Here 2026 da 00:51 UTCresolved

   O portal Insights na região dos Emirados Árabes Unidos está agora a funcionar normalmente após o retrocesso. Validamos a funcionalidade do portal chave e confirmamos que o serviço permanece saudável. Este incidente está agora resolvido.

5. 5 Here 2026 da 22:58 UTCpostmortem

   # # Impacto do Cliente Em ** 1 de outubro de 2026**, o serviço UiPath **Insights** na região de **UAE** não estava disponível. De aproximadamente **23:40 UTC em 1 de outubro a 00:39 UTC em 2 de outubro**, os usuários não puderam carregar painéis Insights: solicitações falharam com um erro após cerca de 10 segundos. Os pedidos de provisão Insights para novos inquilinos na região também falharam. A ruptura durou aproximadamente **59 minutos**. Outros serviços de UiPath na região dos EAU e Insights em todas as demais regiões não foram afetados. Nenhum dado do cliente foi perdido. # # Causa raiz A falha foi causada por uma mudança de configuração ** que foi enviada em uma versão agendada do Insights. A mudança levantou a versão **minimum TLS \(Transport Layer Security\)** nos endpoints da aplicação Insights na região dos EAU de TLS 1.2 para **TLS 1.3**, como parte de um esforço de endurecimento de segurança. O gateway UiPath que direciona o tráfego do cliente para o Insights conecta-se a esses endpoints ao longo do TLS 1.2. Uma vez que os endpoints pararam de aceitar o TLS 1.2, o gateway não poderia mais abrir uma conexão segura a eles. As solicitações do cliente cronometraram e retornaram erros, mesmo que o próprio aplicativo Insights permanecesse saudável. A mudança se aplica apenas à região dos EAU, razão pela qual nenhuma outra região foi afetada. # # Detecção O problema foi detectado pelo monitoramento sintético automatizado da **UiPath, que testa continuamente a disponibilidade do Insights em vários locais. O primeiro exame de saúde falhou foi registrado às 23:40 UTC. Alertas automáticos disparados em minutos e a equipa de engenharia começou a investigar. # # Resposta A equipe de engenharia confirmou que a falha afetava apenas o Insights na região dos EAU. O aplicativo estava rodando normalmente, mas nenhum tráfego de clientes estava atingindo-o. A equipe rastreou a falha no passo de conexão segura entre o gateway e Insights, e ligou-o à configuração TLS aplicada pelo lançamento. Em aproximadamente **00:38 UTC**, a equipe restaurou a versão mínima anterior do TLS \(TLS 1.2\) nos terminais afetados. Os exames de saúde sintéticos começaram a passar imediatamente, e em **00:41 UTC** todos os exames Insights na região dos EAU eram saudáveis. A equipe continuou monitorando para confirmar total estabilidade. # # Acompanhamento Para evitar incidentes semelhantes no futuro, estamos a tomar as seguintes medidas: * **Remova a alteração do TLS da versão** para que futuras implantações não a apliquem novamente, até que o gateway suporte o TLS 1.3 de ponta a ponta. * **Validate connection-security altera contra o gateway** em um ambiente de pré-produção antes de serem aplicados à produção.

Traduzido automaticamente da atualização oficial do incidente.

1. 1 Here 2026 da 18:57 UTCinvestigating

   A partir de 1 de outubro às 13h30 UTC, alguns agentes, incluindo agentes de código baixo e codificados, começaram a ter falhas em todas as regiões ao usar gemini-3.1-pro-preview e gpt-4o-2024-05-13. Estes modelos também podem estar indisponíveis para seleção durante o projeto do agente. Estamos a investigar e a trabalhar numa solução.

2. 1 Here 2026 da 19:05 UTCidentified

   Identificámos o problema e estamos a lançar uma solução. Os agentes que usam os modelos afetados podem continuar a experimentar falhas, e os modelos podem permanecer indisponível para seleção durante o projeto do agente, enquanto a implantação completa.

3. 1 Here 2026 da 19:46 UTCresolved

   Revertemos a mudança que causou esta questão e confirmamos que os modelos afetados estão novamente disponíveis. Alguns agentes podem continuar a experimentar falhas intermitentes enquanto as instâncias atualizam. Continuamos a monitorar o design e execução do agente para gemini-3.1-pro-preview e gpt-4o-2024-05-13.

4. 7 Here 2026 da 10:15 UTCpostmortem

   # # Impacto do cliente Em 1 de outubro de 2026, das 14:31 às 19:40 UTC, agentes configurados com alguns modelos de linguagem grande, incluindo Gemini 3.1 Pro Preview e GPT-4o (2024-05-13), não conseguiram iniciar em todas as regiões, com um erro dizendo que o modelo não está disponível. Os mesmos modelos estavam faltando na lista de modelos ao projetar agentes. Agentes que utilizaram outros modelos não foram afetados. # # Causa raiz Uma bandeira de recurso foi virada, fazendo com que o serviço dos agentes começasse a enviar um código de operação para pedidos de descoberta de modelos. Isso fez com que a lista de modelos servisse de operação específica em oposição à lista de modelos de agentes de base. A lista de modelos por operação foi inicialmente semeada a partir da configuração Bring Your Own Model (ByOM) de modelos superridáveis, que crucialmente para os agentes não tinham paridade com a lista completa de modelos suportados no serviço Agentes. A auditoria interna mostrou que se tratava de um erro e não de uma lacuna intencional. Ao longo do tempo, essa lacuna nunca foi abordada e após o interruptor de bandeira, agentes já configurados com qualquer um dos modelos afetados falhariam por causa de sua ausência da lista devolvida. # # Detecção Um cliente relatou o problema, e ele foi aumentado para nossos engenheiros às 16:44 UTC. Nosso monitoramento não alertou, pois esse erro geralmente aponta para problemas de configuração de nível de organização ou agente. # # Resposta Os engenheiros rastrearam as falhas até a mudança de configuração e reverteram-na às 19:01 UTC. O reverso fez efeito nos minutos seguintes, e a última falha ocorreu às 19:40 UTC. # # Acompanhamento 1. As listas de modelos serão alinhadas antes desta mudança ser feita novamente. 2. Estamos mudando como este erro é classificado de modo que um pico de plataforma-larga alerta nossos engenheiros.

Traduzido automaticamente da atualização oficial do incidente.

1. 1 Here 2026 da 18:17 UTCinvestigating

   A partir de 1 de outubro, aproximadamente às 12:00 horas UTC, os usuários da comunidade na Europa podem ter falhas em agentes de LowCode que usam aplicativos de ação locais. Confirmámos que o impacto se limita aos utilizadores comunitários na Europa. Estamos ativamente investigando a questão, determinando a extensão das falhas, e trabalhando em uma correção.

2. 1 Here 2026 da 18:25 UTCidentified

   Identificámos a questão que causa falhas em agentes de baixo código que utilizam aplicações de acção local para utilizadores comunitários na Europa. Estamos recuando as mudanças anteriores e continuando a monitorar a recuperação. Nós forneceremos outra atualização uma vez que o rollback estiver completo ou se tivermos informações adicionais para compartilhar.

3. 1 Here 2026 da 20:08 UTCresolved

   Confirmámos que o regresso foi concluído e que a questão que afecta os agentes de baixo código que utilizam aplicações de acção local para utilizadores comunitários na Europa foi resolvida. Os serviços recuperaram e vamos encerrar este incidente.

4. 7 Here 2026 da 14:28 UTCpostmortem

   # # Impacto do cliente Em 1o de outubro de 2026, das 10:50 às 19:50 UTC, alguns usuários do Studio Web na Europa não puderam depurar agentes que chamam processos Orchestrator (RPA, agentes, etc.) ou aplicativos de ação da mesma solução. A chamada falhou com um erro "não encontrado". Os agentes publicados e os postos de trabalho de produção não foram afectados. # # Causa raiz Uma atualização do Studio Web mudou como os recursos da solução estão localizados durante a depuração. Faltava uma configuração que mantivesse o comportamento anterior, então a depuração foi executada procurando os recursos da solução no espaço de trabalho pessoal do usuário em vez da pasta de depuração. # # Detecção Testes automatizados de ponta a ponta alertaram nossos engenheiros às 16:43 UTC. O conjunto de testes de ponta a ponta é executado uma vez a cada 2 horas e o alerta só acontece após 3 falhas de teste consecutivas. O problema também foi relatado a partir de um ambiente de cliente. # # Resposta Depois de identificar a causa raiz, um retrocesso foi iniciado às 18:00 UTC e foi totalmente em vigor às 19:50 UTC. Essa duração incluiu uma falha de implantação que teve que ser tentada novamente, que levou 50 minutos. Uma versão corrigida que inclui a configuração foi implantado em 2 de outubro às 13:00 UTC. # # Acompanhamento 1. A configuração agora faz parte da linha de código principal, então futuras versões incluem-no. 2. Estamos melhorando os alertas e o conjunto de testes de ponta a ponta para pegar regressões mais cedo.

Traduzido automaticamente da atualização oficial do incidente.

1. 1 Here 2026 da 16:32 UTCresolved

   Entre 14:23 e 16:04 UTC em 1 de outubro de 2026, algumas solicitações para excluir itens nos serviços da UiPath Automation Cloud na região da Austrália falharam com erros "404 Not Found". Os serviços afetados incluíram Orquestrador, Compreensão de Documentos, Centro de IA e Serviço de Dados. Outras operações, como visualização, criação e atualização de itens, funcionaram normalmente. A causa foi uma mudança de configuração para o nosso roteamento de pedidos. Rebocámo-lo e o serviço está totalmente restaurado.

2. 7 Here 2026 da 10:15 UTCpostmortem

   # # Impacto do cliente Entre 1 de outubro de 2026 às 2:23 pm UTC e 4:04 pm UTC, um subconjunto de clientes experimentou **404 Not Found** errors for some UiPath Automation Cloud requests in the Australia region. O incidente durou 1 hora e 41 minutos. Os pedidos afetados incluíram operações de exclusão e algumas verificações de conexão com o robô. Os serviços afetados incluíram Orquestrador, Compreensão de Documentos, Centro de IA e Serviço de Dados. Os trabalhos de robô que chamaram Orchestrator podem ter falhado, e os clientes podem precisar de repetir quaisquer trabalhos de robô que falharam durante esta janela. Todas as outras operações não foram afectadas. # # Causa raiz Uma mudança de configuração de roteamento foi aplicada na região da Austrália com um conjunto incompleto de operações suportadas devido a um tempo limite no oleoduto de lançamento. Excluir operações estavam faltando na configuração, então essas solicitações foram rejeitadas na camada de roteamento com **404 Not Found** antes de alcançar os serviços subjacentes. # # Detecção Monitorização automatizada de ponta a ponta detectou o problema, alertando para as falhas de verificação dos serviços de compreensão de documentos. Nossa equipe de engenharia então usou dados de monitoramento interno para confirmar o padrão mais amplo de falhas nos serviços afetados. # # Resposta Durante a investigação, os dados de monitoramento mostraram que os pedidos encaminhados pela região da Austrália estavam retornando **404 Not Found** erros, enquanto os pedidos encaminhados por outras regiões não foram afetados. A análise identificou que o tempo de início de **404 Not Found** o aumento de resposta foi correlacionado com o tempo em que a configuração de roteamento entrou em vigor. A equipe reverteu a configuração de roteamento para a versão de trabalho anterior. Após o reverso, o monitoramento mostrou contagem de erros caindo em aproximadamente três minutos, sendo o serviço totalmente restaurado em 1o de outubro de 2026 às 16h04 UTC. # # Acompanhamento 1. Melhorar alertas de camada de roteamento em 4xx alterações basais 2. Detectar configurações de roteamento parcialmente aplicadas antes de fazê-los fazer efeito

Traduzido automaticamente da atualização oficial do incidente.