Histórico de interrupções do Uipath

1. 3 Gwengolo 2026 da 15:34 UTCinvestigating

   Estamos actualmente a investigar a questão

2. 3 Gwengolo 2026 da 15:39 UTCidentified

   A questão foi identificada e as medidas de mitigação adequadas foram implementadas para abordá-la.

3. 3 Gwengolo 2026 da 15:47 UTCmonitoring

   A questão foi resolvida com sucesso e o serviço foi totalmente restaurado. O serviço funciona normalmente neste momento.

4. 3 Gwengolo 2026 da 16:17 UTCresolved

   A questão foi resolvida com sucesso e o serviço foi totalmente restaurado. O serviço funciona normalmente neste momento.

Traduzido automaticamente da atualização oficial do incidente.

1. 4 Gwengolo 2026 da 17:48 UTCresolved

   O painel Insights no Looker experimentou um problema que impediu as últimas corridas do Maestro, de aparecer no painel Regiões afectadas : EUA, SEA, IND, CA, AUE, JP , UK Linha temporal do incidente Começou: 2 de Setembro de 2026 às 20:00 UTC Resolução: 4 de setembro de 2026 às 16:30:00 UTC O problema foi resolvido atualmente, e o painel Insights está exibindo os últimos dados de execução do Maestro.

Traduzido automaticamente da atualização oficial do incidente.

1. 1 Gwengolo 2026 da 13:49 UTCinvestigating

   Estamos investigando relatórios de desempenho degradado impactando digitalização e extração para compreensão de documentos e IXP nos EUA. Impacto: Os usuários podem experimentar lentidão e falha no documento Compreender as operações de execução. Nossas equipes estão trabalhando para identificar a causa e compartilharão mais detalhes à medida que a investigação avança.

2. 1 Gwengolo 2026 da 14:07 UTCmonitoring

   Identificamos a questão e aplicamos uma mitigação. Os serviços são devolvidos ao estado saudável e estamos monitorando os serviços.

3. 1 Gwengolo 2026 da 15:06 UTCresolved

   Esta questão foi totalmente resolvida e os serviços são agora estáveis. Publicaremos mais detalhes do incidente na página de status em breve.

Traduzido automaticamente da atualização oficial do incidente.

1. 31 Eost 2026 da 16:55 UTCinvestigating

   Estamos neste momento a investigar a questão.

2. 31 Eost 2026 da 17:07 UTCidentified

   Identificámos a questão e implementámos a solução necessária

3. 31 Eost 2026 da 18:24 UTCmonitoring

   A questão foi atenuada e o serviço está atualmente operacional. Continuaremos a acompanhar de perto a saúde dos serviços e a tomar novas medidas, se necessário.

4. 31 Eost 2026 da 19:39 UTCresolved

   A questão foi atenuada e o serviço está atualmente operacional. Continuaremos a acompanhar de perto a saúde dos serviços e a tomar novas medidas, se necessário.

Traduzido automaticamente da atualização oficial do incidente.

1. 28 Eost 2026 da 15:41 UTCidentified

   A questão foi identificada, e a equipe está trabalhando ativamente na implantação de uma correção. Esperamos que o destacamento comece nas próximas horas.

2. 28 Eost 2026 da 17:27 UTCmonitoring

   Identificamos a causa raiz do desempenho degradado e estamos no processo de implantação de uma correção nas próximas horas. Ele afeta consultas vinculadas onde o usuário não tem acesso à pasta original. A superfície da API não é afetada. Exportar via CSV pode ser usado como uma solução alternativa. Atualizações adicionais serão fornecidas enquanto avançamos para a resolução.

3. 28 Eost 2026 da 17:39 UTCidentified

   Identificamos a causa raiz do desempenho degradado e estamos no processo de implantação de uma correção nas próximas horas. Ele afeta consultas vinculadas onde o usuário não tem acesso à pasta original. A superfície da API não é afetada. Exportar via CSV pode ser usado como uma solução alternativa. Atualizações adicionais serão fornecidas enquanto avançamos para a resolução.

4. 28 Eost 2026 da 20:00 UTCidentified

   A correção está sendo aplicada atualmente. Providenciaremos outra atualização logo que a implantação tenha sido concluída em todas as regiões afetadas.

5. 28 Eost 2026 da 22:57 UTCresolved

   A correção foi implantada com sucesso em todas as regiões, e nós validamos que o problema está resolvido. O serviço está funcionando como esperado.

6. 3 Gwengolo 2026 da 08:49 UTCpostmortem

   # # Impacto do cliente Entre 28 de agosto de 2026 às 15:23 UTC e 28 de agosto de 2026 às 10:57 UTC, um subconjunto de clientes experimentou erros ao abrir painéis de detalhes de itens de fila no Orchestrator. O caminho afetado devolveu uma página 404 para as filas LINKED quando o usuário NÃO teve acesso à pasta original em que os itens foram criados. O impacto afetou apenas as interações do Orchestrator UI e abrangeu todas as regiões que executavam a versão de software afetada. O acesso à interface de programação de aplicativos do Orchestrator não foi afetado, e exportar dados de fila para CSV estava disponível como solução alternativa. A duração total foi de aproximadamente 7 horas. # # Causa raiz O incidente foi causado por uma regressão na interface de usuário do Orchestrator para filas vinculadas acessadas de outras pastas. A regressão não lidou corretamente com o fluxo de detalhes da fila vinculada quando o usuário solicitante não teve acesso à pasta original, o que fez com que o painel de detalhes do item da fila encaminhasse para uma página 404 em vez de exibir as informações esperadas. # # Detecção O problema foi detectado através de um alerta de incidente automatizado para a frente do Orchestrator em 28 de agosto de 2026, às 15:23 UTC. # # Resposta Às 15h31 UTC de 28 de agosto de 2026, nossa equipe de engenharia descreveu o problema como sendo impossível aos clientes acessarem painéis de detalhes de itens de fila devido a uma regressão. Às 3:41 pm UTC, uma atualização do status público confirmou que a causa raiz tinha sido identificada, que uma correção estava sendo implantada, e que o acesso à interface de programação de aplicativos não foi afetado. Às 17h27 UTC, o escopo foi reduzido para filas vinculadas onde o usuário não teve acesso à pasta original. Às 17:29 horas UTC, a equipe determinou que a correção inicial não abordava totalmente o cenário afetado, e uma correção corrigida foi desenvolvida. Às 17h30 UTC, o cenário afetado foi reproduzido e o correção corrigido foi validado localmente. Às 5:39 pm UTC, uma atualização de página de status documentou a exportação de CSV como uma solução alternativa. A implantação da correção corrigida continuou nas regiões afetadas. Às 22h50 UTC, a solução foi confirmada em todo o lado. Às 10h57 UTC, o incidente foi marcado resolvido e a página de status foi atualizada para confirmar que o serviço estava funcionando como esperado. # # Acompanhamento As ações formais de acompanhamento estão sendo monitoradas através do processo de revisão pós-incidente iniciado na resolução. # # Itens de ação - Expandindo nossos casos de teste automatizados para incluir este cenário, e outros cenários similares relacionados a objetos vinculados ou cenários de pastas cruzadas. - Garantindo que podemos desligar qualquer mudança através de uma bandeira para um tempo de resposta mais rápido.

Traduzido automaticamente da atualização oficial do incidente.

1. 27 Eost 2026 da 17:16 UTCinvestigating

   Estamos a investigar relatórios de registos de robôs desaparecidos na região dos EUA. Nossas equipes estão trabalhando para identificar a causa e compartilharão mais detalhes à medida que a investigação avança.

2. 27 Eost 2026 da 18:53 UTCidentified

   Identificámos que a ingestão de logs de robôs estava atrasada. Registros de robôs estão alcançando dados ao vivo e estamos monitorando a recuperação.

3. 27 Eost 2026 da 20:31 UTCmonitoring

   Os logs agora estão povoando como esperado em tempo real e continuaremos monitorando a aplicação.

4. 27 Eost 2026 da 21:57 UTCresolved

   O problema foi resolvido e logs estão povoando como esperado.

Traduzido automaticamente da atualização oficial do incidente.

1. 25 Eost 2026 da 09:41 UTCidentified

   Identificamos um problema que afeta o recurso de implantação de soluções no Studio Web na região do Japão, onde implantações de soluções podem falhar. Uma correção foi preparada e será lançada em breve. Forneceremos atualizações adicionais à medida que mais informações estiverem disponíveis.

2. 25 Eost 2026 da 09:47 UTCmonitoring

   A solução foi implantada com sucesso na região do Japão, e a questão foi atenuada. Estamos monitorando de perto o serviço para garantir que a implantação da solução continue funcionando como esperado e forneceremos atualizações adicionais conforme necessário.

3. 25 Eost 2026 da 10:12 UTCresolved

   O problema foi resolvido, e a implantação de soluções no Studio Web está funcionando como esperado na região do Japão. Não foi observado qualquer impacto adicional.

Traduzido automaticamente da atualização oficial do incidente.

1. 25 Eost 2026 da 03:58 UTCinvestigating

   Estamos investigando um problema que afeta os clientes usando Insights na região de Singapura, onde os painéis podem não carregar e exibir erros de tempo. Nossas equipes estão trabalhando para identificar a causa raiz e fornecerão atualizações adicionais à medida que mais informações estiverem disponíveis.

2. 25 Eost 2026 da 04:37 UTCmonitoring

   A questão foi atenuada, e estamos acompanhando de perto o serviço Insights na região de Singapura para garantir que os painéis continuem a carregar como esperado.

3. 25 Eost 2026 da 04:53 UTCresolved

   A questão foi resolvida, e o serviço Insights na região de Singapura está a funcionar como esperado. Não foi observado qualquer impacto adicional.

4. 4 Gwengolo 2026 da 11:46 UTCpostmortem

   # # Impacto do cliente Entre 25 de agosto de 2026 às 3:42 UTC e 25 de agosto de 2026 às 4:53 UTC, clientes usando Insights na região de Singapura experimentaram falhas carregando painéis Insights. Usuários afetados viram páginas do painel passarem o tempo ou não carregarem, e erros de servidor foram observados para solicitações de serviço relacionadas. O impacto primário foi o acesso ao painel Insights, incluindo gráficos e alertas. Um serviço de infraestrutura relacionado também retornou erros de servidor durante o incidente, mas o acesso ao painel de controle havia se recuperado antes da resolução final. # # Causa raiz O incidente foi atribuído a uma perturbação regional do serviço da Microsoft em Singapura, afectando a infra-estrutura utilizada pelo serviço Insights. Durante a interrupção, o serviço Insights não foi capaz de atender de forma confiável as solicitações do painel, resultando em tempo limite de solicitação e erros no servidor. Nenhuma mudança foi feita do nosso lado. O serviço recuperado como a perturbação regional da Microsoft foi resolvido, e a Microsoft posteriormente relatou um problema de serviço regional em Singapura em sua página de status. Foi solicitada à Microsoft uma análise formal da causa raiz para confirmar o mecanismo de falha específico e identificar quaisquer medidas preventivas ou de atenuação adicionais. # # Detecção O monitoramento automatizado da saúde do serviço Insights detectou o problema em 25 de agosto de 2026 às 3:42 UTC. O impacto do cliente foi confirmado na ponte de resposta logo após a detecção. # # Resposta Em 25 de agosto de 2026 às 3:58 UTC, nós postamos uma atualização de status público observando que os painéis Insights na região de Singapura podem não carregar e exibir erros de tempo-out. Durante a resposta, nossa equipe de engenharia verificou erros de servidor em monitoramento automatizado, tentou acessar diagnósticos de serviços e iniciou um procedimento de recuperação na infraestrutura subjacente. Em 25 de agosto de 2026 às 4:01 UTC, o serviço Insights recuperou enquanto o procedimento de recuperação estava em andamento, e o carregamento do painel foi validado em várias contas de teste. Em 25 de agosto de 2026, às 4:37 da manhã, mudamos o incidente para monitoramento depois de confirmar os painéis carregados com sucesso. Um serviço de infraestrutura relacionado recuperado em 25 de agosto de 2026 às 4:49 UTC, e o incidente foi marcado resolvido em 25 de agosto de 2026 às 4:53 UTC. # # Acompanhamento 1. Solicite uma análise da causa raiz da Microsoft para a ruptura regional de Singapura que afeta o problema de carregamento de painéis insights.

Traduzido automaticamente da atualização oficial do incidente.

1. 25 Eost 2026 da 03:44 UTCinvestigating

   Estamos investigando um problema que afeta os clientes usando a funcionalidade Extended OCR no serviço Document Understanding na região de Singapura. Nossas equipes estão trabalhando para identificar a causa raiz e fornecerão atualizações adicionais à medida que mais informações estiverem disponíveis.

2. 25 Eost 2026 da 04:04 UTCmonitoring

   A questão foi atenuada, e estamos a acompanhar de perto o serviço para garantir que continua a funcionar como esperado. Forneceremos atualizações adicionais à medida que mais informações estiverem disponíveis.

3. 25 Eost 2026 da 04:59 UTCresolved

   O problema foi resolvido, e o serviço está funcionando como esperado. Não foi observado qualquer impacto adicional.

4. 27 Eost 2026 da 03:42 UTCpostmortem

   # # Impacto do cliente Em 25 de agosto de 2026, pedidos de OCR estendidos no serviço de compreensão de documentos falhou com 500 código de status na região de Singapura por aproximadamente 33 minutos, entre 03:08 e 03:41 UTC. A causa foi uma perturbação do serviço regional da Microsoft em Singapura. Todas as outras funcionalidades do Document Understanding não foram afetadas e nenhuma outra região foi afetada. # # Causa raiz A falha foi atribuída a uma interrupção regional do serviço Microsoft em Cingapura afetando os recursos usados pela capacidade de OCR Extended. Nenhuma mudança foi feita do nosso lado, e a Microsoft posteriormente atualizou sua própria página de status para refletir uma questão regional de Singapura. Foi solicitada uma análise formal da causa raiz à Microsoft. # # Detecção Um alerta automatizado para o serviço Document Understanding disparou em 25 de agosto de 2026 às 3:13 UTC. O alerta foi prontamente reconhecido, e o incidente foi declarado cliente-impactando em minutos. # # Resposta O engenheiro de plantão explorou o impacto na região de Singapura. Os respondedores descartaram uma atualização recente do serviço como causa, já que a mesma atualização havia sido implantada em outras regiões sem impacto comparável, o que apontou para uma falha de dependência regional fora de nossa infraestrutura. Como a falha se originou em um serviço Microsoft upstream, nenhuma ação atenuante estava disponível ou necessária no lado UiPath. As solicitações começaram a ter sucesso novamente às 03:41 UTC à medida que a dependência da Microsoft se recuperava. Os respondentes realizaram o incidente aberto para verificar a recuperação sustentada: dez minutos de tráfego limpo foram confirmados às 03:51 UTC, o incidente mudou para Monitoramento às 04:04 UTC, e foi resolvido às 04:59 UTC após a estabilidade contínua, sem mais falhas. # # Acompanhamento 1. Solicitou uma análise raiz da causa da Microsoft para a ruptura regional de Singapura afetando dependências estendidas do OCR, incluindo como a recorrência pode ser evitada.

Traduzido automaticamente da atualização oficial do incidente.

1. 24 Eost 2026 da 10:43 UTCidentified

   Identificamos a causa de um problema impactando um pequeno número de clientes usando o UiPath Apps de autoria do serviço Web Studio em várias regiões. Nossas equipes estão prontas com uma correção, e a implantação está prestes a começar nas regiões afetadas. Continuaremos a monitorar a implantação e fornecer novas atualizações à medida que a correção produz efeito.

2. 24 Eost 2026 da 11:30 UTCmonitoring

   A correção foi implantada com sucesso em todas as regiões afetadas, e o problema foi atenuado. Estamos monitorando de perto o serviço para garantir que a correção continue a funcionar como esperado e forneceremos atualizações adicionais conforme necessário.

3. 24 Eost 2026 da 11:55 UTCresolved

   O problema foi resolvido, e o serviço está funcionando como esperado. Não foi observado qualquer impacto adicional.

4. 1 Gwengolo 2026 da 11:47 UTCpostmortem

   # # Impacto do cliente Entre 19 de agosto de 2026 às 2:33 pm UTC e 24 de agosto de 2026 às 11:30 UTC, um subconjunto de clientes não pôde carregar projetos UiPath Apps de autoria do Studio Web. Os clientes afetados experimentaram total indisponibilidade de projetos Apps em vez de lentidão ou desempenho degradado. O impacto foi limitado a um pequeno conjunto de clientes, cujo serviço Apps foi hospedado na região do Japão. A duração total de impacto do cliente foi de aproximadamente 4 dias e 21 horas. # # Causa raiz A causa raiz foi um descompasso de implantação entre o Studio Web e UiPath Apps. Em 19 de agosto de 2026, a Studio Web recebeu uma atualização programada na região da UE que incluiu uma atualização do quadro. A atualização correspondente do UiPath Apps contendo a atualização do framework ainda não havia sido implantada para a unidade de escala do Japão. Uma atualização anterior do Apps que já era compatível com a nova versão de framework foi implantada em todas as regiões, exceto no Japão, onde a implantação tinha sido adiada por razões não relacionadas. Como resultado, a região do Japão ainda estava executando uma versão mais antiga do Apps que não era compatível com o Studio Web atualizado. # # Detecção O problema foi relatado por um cliente através de sua equipe de conta UiPath em 24 de agosto de 2026 às 9:36 UTC. Um incidente foi aberto às 10:21 UTC, e um incidente na página de status público foi declarado dentro de um minuto. O monitoramento automatizado existente não detectou o problema porque valida combinações de implantação combinadas; melhorar a detecção de configurações mistas faz parte do nosso plano de acompanhamento. # # Resposta Poucos minutos após a abertura do incidente, identificamos o descompasso de implantação como a causa raiz e decidimos acelerar a implantação da atualização correspondente do UiPath Apps para todas as regiões afetadas, alinhando Apps com a versão do Studio Web já sendo servido aos clientes impactados. Às 10:43 da manhã, nós postamos uma atualização do status público confirmando que a causa tinha sido identificada e que a correção estava sendo implantada. Às 10:52 UTC, a implantação estava em curso para as restantes regiões, com várias regiões já concluídas. Às 11h30 UTC, confirmamos que a solução foi implantada em todas as regiões afetadas e marcamos o incidente atenuado. Às 11h55 UTC, após o monitoramento não ter mais impacto, o incidente foi marcado como resolvido. # # Acompanhamento 1. Adicione alerta automatizado sobre a telemetria de produção para detectar falhas de carga Apps correlacionadas com a versão Studio Web que está sendo servido. 2. Implemente o monitoramento sintético que carrega regularmente um projeto Apps de autoria do Studio Web através de configurações representativas do cliente e alertas sobre falha. 3. Ajuste o sequenciamento de lançamento para as mudanças do Studio Web e Apps firmemente acoplados para que as atualizações de Apps dependentes sejam totalmente implantadas em todas as regiões antes que a experiência mais recente do Studio Web atinja o tráfego do cliente.

Traduzido automaticamente da atualização oficial do incidente.

1. 21 Eost 2026 da 12:37 UTCmonitoring

   Foi implementada uma correção para o problema impactando a classificação e extração de documentos para a compreensão de documentos nos EUA, e estamos atualmente monitorando os resultados.

2. 21 Eost 2026 da 13:36 UTCresolved

   A questão que tem impacto na classificação e extração de documentos para a compreensão de documentos na região dos EUA foi resolvida. Após um período de acompanhamento, o serviço é confirmado saudável e operacional normalmente.

3. 27 Eost 2026 da 03:46 UTCpostmortem

   # # Impacto do cliente Entre 21 de agosto de 2026 às 11:05 UTC e 21 de agosto de 2026 às 12:18 UTC, um subconjunto de clientes experimentou operações de compreensão de documentos falhadas, incluindo classificação de documentos, extração e digitalização. A duração estimada da interrupção parcial foi de 48 minutos. O impacto foi limitado aos clientes que utilizaram o Document Understanding na região dos EUA. # # Causa raiz O incidente foi causado pela configuração de failover do banco de dados de armazenamento Document Understanding entrando em um estado quebrado durante uma operação de escalonamento do banco de dados preventivo. O escalonamento foi iniciado após a aproximação do banco de dados ao seu limite de armazenamento. Durante a operação, o banco de dados secundário não pôde ser escalado, a tentativa de remoção da configuração failover falhou, e o provedor de plataforma de banco de dados teve que quebrar o link de replicação. Isso deixou a configuração do failover em um estado temporariamente indisponível, fazendo com que os serviços de armazenamento e execução que dependem desse banco de dados falhem as solicitações. # # Detecção O incidente foi detectado através de um alerta automatizado para os serviços de compreensão de documentos, que foi reconhecido em 21 de agosto de 2026 às 12:10 horas UTC. # # Resposta Antes da declaração do incidente de impacto do cliente, a escala do banco de dados primário foi completada e o suporte do provedor da plataforma de banco de dados foi engajado para a questão do banco de dados secundário. Depois que a configuração do failover foi quebrada, exploramos redirecionar a conexão de serviço, mas não conseguimos identificar um caminho seguro e imediato para fazê-lo, dada a configuração atual do serviço. O serviço foi restaurado através da exclusão do banco de dados secundário não saudável e da recriação da configuração do failover. Em 21 de agosto de 2026 às 12:37 horas UTC, a correção tinha sido implementada e o monitoramento estava em andamento. Às 13h36 UTC, o acompanhamento confirmou que o serviço era saudável e o incidente foi marcado como resolvido. # # Acompanhamento 1. Solicite uma análise de causa raiz do provedor de plataforma de banco de dados para determinar por que o banco de dados secundário não poderia ser escalado e por que a remediação de configuração failover exigiu replicação de quebra. 2. Atualizar os limiares de alerta de armazenamento de banco de dados e roteamento para que os alertas são atribuídos e agiu mais cedo, incluindo um aviso de menor gravidade em 75% de uso e um alerta de maior gravidade em 85% de uso.

Traduzido automaticamente da atualização oficial do incidente.

1. 19 Eost 2026 da 16:34 UTCinvestigating

   Estamos investigando uma questão que pode afetar alguns clientes usando Claude Sonnet 4.6 em Agentes na região dos EUA. Nossa equipe de engenharia está trabalhando ativamente para entender o problema e compartilhará novas atualizações quando mais informações estiverem disponíveis.

2. 19 Eost 2026 da 16:40 UTCmonitoring

   Mitigamos a questão. Nossa equipe de engenharia é ativamente de manhã e compartilhará novas atualizações à medida que mais informações estiverem disponíveis.

3. 19 Eost 2026 da 16:42 UTCmonitoring

   Mitigamos a questão. Nossa equipe de engenharia está monitorando ativamente e compartilhará novas atualizações à medida que mais informações estiverem disponíveis.

4. 19 Eost 2026 da 16:55 UTCresolved

   A questão foi resolvida.

5. 31 Eost 2026 da 12:41 UTCpostmortem

   # # Impacto do Cliente Entre 19 de agosto de 2026 às 13h36 UTC e 19 de agosto de 2026 às 15h53 UTC, um subconjunto de clientes recebeu erros ao usar Claude Sonnet 4.6 em Agentes. O impacto durou aproximadamente 2 horas e 17 minutos. O impacto foi para os clientes usando agentes na região dos EUA. Erros também foram observados para Claude Opus 4.6 e Claude Opus 4.5, que são usados em menor volume. --- # # Causa raiz Como parte de uma migração de infraestrutura planejada, mudamos o serviço de plataforma que encaminha pedidos de modelo para agentes para um novo sistema de entrega de configuração, região por região. A nova fonte de configuração estava faltando as entradas de roteamento para três modelos Claude — Claude Sonnet 4.6, Claude Opus 4.6, e Claude Opus 4.5. Sem essas entradas, o serviço não poderia resolver um destino válido para pedidos para esses modelos, e os rejeitou com erros. Outros modelos não foram afetados e continuaram a servir normalmente durante todo o período. --- # # Detecção O problema foi detectado através de escaladas de clientes em 19 de agosto de 2026 às 2:55 pm UTC — aproximadamente 1 hora e 19 minutos após o primeiro pedido afetado. Nossa equipe de engenharia ponderou a questão para modelos específicos de Claude e começou a investigação. A comunicação de status público começou às 15:08 UTC. Nosso monitoramento de alerta é baseado em taxas de erro agregadas. Embora quase todas as solicitações aos três modelos afetados estivessem falhando, esses modelos representavam uma pequena parcela do tráfego global na região, de modo que o sinal agregado não cruzou nossos limiares de alerta e a questão não foi levantada automaticamente. Esta é a lacuna de detecção abordada no seguimento abaixo. --- # # Resposta Às 3:25 pm UTC, a fonte de configuração incompleta foi identificada como a causa, e uma correção foi iniciada. Às 3:47 pm UTC, a implantação da correção estava em andamento, e o serviço foi monitorado ativamente à medida que a mudança se desenrolava. Por volta das 15h59 UTC, os registros de serviço confirmaram que o problema foi atenuado, e às 16h00 UTC a taxa de falha foi confirmada em 0%. O incidente foi marcado mitigado às 4:40 pm UTC, e resolução completa foi declarada às 4:55 pm UTC após monitoramento contínuo e confirmação do cliente de que o serviço estava funcionando como esperado. --- # # Acompanhamento A migração de infraestrutura foi concluída em todas as regiões e a configuração de roteamento agora vem de uma única fonte, removendo o descompasso que causou este incidente para que ele não possa voltar. Verificações automatizadas estão sendo introduzidas para verificar continuamente todos os modelos suportados em cada região, de modo que um modelo não disponível é detectado e alertado imediatamente — inclusive em regiões de baixo tráfego.

Traduzido automaticamente da atualização oficial do incidente.

1. 18 Eost 2026 da 17:54 UTCinvestigating

   Estamos a investigar relatórios de uma falha na avaliação da expressão relacionada com os parâmetros de saída da tarefa HITL para o Asgentic Orchestratron em utilizadores comunitários na Europa. Impacto: Os usuários podem não ser capazes de completar 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. 18 Eost 2026 da 20:31 UTCidentified

   Identificou-se a causa de uma interrupção que impactava as avaliações de expressão relacionadas com os parâmetros de saída da tarefa HITL para a Orquestração Agentiva em usuários comunitários na Europa. Impacto: Os usuários terão falhas quando tiverem expressões usando o parâmetro de saída de tarefa HITL. Próxima atualização: Nossas equipes estão trabalhando para entender a causa e escopo e compartilharão atualizações conforme disponíveis.

3. 18 Eost 2026 da 21:45 UTCidentified

   Identificámos a solução e a resolução está em curso. Próxima atualização: Nossas equipes estão trabalhando na correção e compartilharão atualizações conforme disponível.

4. 18 Eost 2026 da 22:53 UTCmonitoring

   Implementámos a solução e estamos a monitorizar a resolução. Próxima atualização: Nossas equipes estão monitorando a resolução e compartilharão atualizações conforme disponível.

5. 18 Eost 2026 da 23:25 UTCresolved

   A falha foi resolvida e a Orquestração Agentic está totalmente operacional. Impacto: Nenhum impacto contínuo do usuário.

Traduzido automaticamente da atualização oficial do incidente.

1. 18 Eost 2026 da 12:08 UTCidentified

   Identificamos a causa raiz de um problema no Studio Web onde a tela de configuração de recursos para alterar atributos de recursos não está carregando. Estamos a colocar uma solução.

2. 18 Eost 2026 da 13:05 UTCidentified

   A implantação da correção está em andamento. Forneceremos mais atualizações à medida que a implantação avança.

3. 18 Eost 2026 da 14:06 UTCidentified

   A correção foi verificada e está sendo lançada em todas as regiões restantes. Estamos monitorando a implantação e recuperação. Obrigado pela paciência.

4. 18 Eost 2026 da 17:03 UTCidentified

   A implantação está a progredir conforme previsto nas restantes regiões. Continuamos a monitorizar o destacamento. Obrigado pela vossa paciência.

5. 18 Eost 2026 da 18:12 UTCmonitoring

   A implantação está a progredir conforme previsto nas restantes regiões. Continuamos a monitorizar o destacamento. Obrigado pela vossa paciência.

6. 18 Eost 2026 da 19:05 UTCresolved

   A implantação está concluída e a questão deve ser resolvida.

Traduzido automaticamente da atualização oficial do incidente.

1. 18 Eost 2026 da 05:32 UTCinvestigating

   Estamos investigando um problema que afeta contas comunitárias onde entidades recém-criadas podem levar aproximadamente uma hora para aparecer no Studio Web. Nenhum dado é perdido, e as entidades existentes não são afetadas.

2. 18 Eost 2026 da 06:48 UTCinvestigating

   Continuamos a investigar o problema e estamos trabalhando para identificar a causa raiz e restaurar os tempos normais de processamento.

3. 18 Eost 2026 da 08:44 UTCinvestigating

   Continuamos a investigar o problema que afeta um subconjunto de inquilinos na Europa, Estados Unidos e Japão, onde entidades recém-criadas podem levar mais tempo do que o esperado para aparecer no Studio Web. Nenhum dado é perdido, e as entidades existentes não são afetadas.

4. 18 Eost 2026 da 09:37 UTCidentified

   Identificámos a causa e estamos a trabalhar numa resolução para a questão que afecta um subgrupo de inquilinos na Europa, nos Estados Unidos e no Japão. Obrigado pela vossa paciência.

5. 18 Eost 2026 da 11:19 UTCmonitoring

   A questão foi atenuada, e esperamos que os tempos de processamento voltem ao normal em breve. Estamos a acompanhar de perto a recuperação. Obrigado pela vossa paciência.

6. 18 Eost 2026 da 11:57 UTCresolved

   O problema foi resolvido e o tempo de processamento voltou ao normal. Obrigado pela vossa paciência.

7. 27 Eost 2026 da 03:51 UTCpostmortem

   # # Impacto do cliente Entre 18 de agosto de 2026 às 5:11 UTC e 18 de agosto de 2026 às 11:57 UTC, entidades recém-criadas em um subconjunto de inquilinos da UiPath Cloud poderiam levar mais tempo do que o esperado para aparecer no Studio Web. No momento da avaliação inicial, as entidades recém-criadas estavam aparecendo com um atraso de aproximadamente uma hora. Clientes na Europa, EUA e Japão foram afetados. A própria criação da entidade continuou com sucesso, nenhum dado foi perdido, e as entidades existentes não foram afetadas. # # Causa raiz A questão foi causada por um volume anormalmente alto de pedidos de criação de ativos de um inquilino. Essas solicitações geraram mais eventos do que nosso serviço de indexação de entidade de backend poderia processar na mesma taxa, criando um backlog na fila de processamento de eventos. Como o Studio Web depende deste serviço para exibir entidades recém-criadas, novas entidades apareceram apenas após o backlog ser processado. # # Detecção A questão foi identificada por nossa equipe de engenharia por meio do alerta de latência de processamento de entidade, e um incidente foi declarado às 5:11 UTC em 18 de agosto de 2026. Por volta das 5:23 UTC, a análise confirmou que a última entidade processada estava aproximadamente uma hora atrasada. # # Resposta Às 5:32h UTC, nós postamos uma atualização inicial do cliente observando a visibilidade atrasada para entidades recém-criadas no Studio Web. Por volta de 6:07 am UTC, investigação identificou incomummente alto tráfego de criação de ativos de um inquilino, e às 7:03 am UTC, ajustaram os recursos de banco de dados para o serviço afetado para ajudar a recuperação do processamento. Às 7:59h UTC, a fonte do alto volume de pedidos tinha parado de enviar pedidos, e a fila começou a drenar. Às 9:59h UTC, iniciamos um processo de sincronização de dados para o inquilino afetado, e às 10:31h UTC, removemos os eventos problemáticos em fila para que o processamento normal pudesse ser mais rápido. A profundidade da fila diminuiu de 95 mil itens às 8:34 UTC para 1.000 itens às 11:44 UTC. O incidente foi marcado mitigado às 11:19 UTC após o processamento recuperado substancialmente, e resolvido às 11:57 UTC após o tempo de processamento voltou ao normal. # # Acompanhamento Sincronização de dados do gatilho para o inquilino afetado e monitorar a ingestão até que os dados do inquilino sejam confirmados consistentes. Melhorar o tratamento da entidade na infraestrutura de indexação para que o backlog não seja acumulado a esta taxa.

Traduzido automaticamente da atualização oficial do incidente.

1. 14 Eost 2026 da 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 Eost 2026 da 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 Eost 2026 da 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 Eost 2026 da 10:58 UTCresolved

   Uma tempestade de pedidos em um recurso de modelo raramente usado na IXP Communications Mining fez com que um loop de repetição bloqueasse solicitações síncronas na API de IXP mais ampla. Isso causou pedidos para falhar com 500's como os trabalhadores estavam ocupados com pedidos de longo prazo. O escalonamento automático rapidamente alcançou sua capacidade máxima e a resolução foi feita apenas aplicando uma correção de código que introduziu prazos rígidos para a solicitação da API contribuinte. A tempestade de pedidos começou por volta das 15:10 UTC e detectou uma 15:15 UTC por alarmes automáticos. A resolução foi confirmada por volta das 18:15 UTC. O incidente foi inicialmente atribuído erroneamente apenas ao cliente fazendo a tempestade de pedidos, mas mais tarde foi descoberto que teve impacto em uma gama mais ampla de usuários. Impacto total limitado a um punhado de usuários nos EUA.

2. 18 Eost 2026 da 21:25 UTCpostmortem

   # # Impacto do Cliente Em 12 de agosto de 2026, entre aproximadamente 15:10 e 18:15 UTC, usuários de Mineração de Comunicações (IXP) na região dos Estados Unidos experimentaram falhas intermitentes de solicitação. O incidente foi confinado a uma das unidades de implantação da região, onde os usuários nele viram falhas em rajadas de cinco a dez minutos, com até 5–7% de suas solicitações falhando com erros de 5xx no pico. Entre rajadas o serviço funcionava normalmente, as solicitações eram geralmente bem sucedidas e nenhum dado foi perdido. # # Causa raiz Uma tempestade de pedidos para um recurso de API raramente usado que calcula previsões de aprendizado de máquina na demanda coincidiu com o retreinamento repetido do modelo solicitado. Cada retreinamento de previsões inválidas em cache, transformando cada solicitação em um cálculo multi-minuto. A API não colocou nenhum limite de tempo em quanto tempo um pedido poderia esperar por este cálculo, de modo que esses pedidos de longo prazo ocuparam progressivamente toda a capacidade de processamento de pedidos, causando pedidos não relacionados a falhar. O escalonamento automático atingiu sua capacidade máxima rapidamente e não pôde compensar. # # Detecção O monitoramento automatizado detectou as falhas às 15:15 UTC, cerca de cinco minutos após o início do impacto, e chamou o engenheiro de plantão. O incidente foi inicialmente atribuído apenas ao cliente que gerou a tormenta de solicitação, mas os relatórios dos clientes e outras investigações mostraram que um conjunto mais amplo de usuários foi afetado durante os surtos de falha. # # Resposta O engenheiro de plantão rastreou as falhas até a espera ilimitada no caminho de previsão sob demanda. A capacidade de serviço foi repetidamente restaurada por substituição automática de instância enquanto uma correção de código foi desenvolvida. A correção é um tempo limite rigoroso na solicitação contribuinte, por isso falha rapidamente sem afetar outras solicitações, e foi implantado na região afetada em aproximadamente 18:00 UTC, e a resolução foi confirmada em 18:15 UTC. # # Acompanhamento 1. O tempo-out rigoroso e fixação de carga-sheding foi feito permanente e liberado para todas as regiões (completado 13 de agosto de 2026). 2. Avaliar limites por cliente na computação de previsão sob demanda para que o uso de um único cliente não possa degradar a API compartilhada.

Traduzido automaticamente da atualização oficial do incidente.

1. 10 Eost 2026 da 14:11 UTCinvestigating

   Estamos investigando o desempenho degradado impactando os Serviços Front-End em Document Understanding em toda a região da GXP East US. Impacto: Os usuários podem notar timeouts ao acessar a UI no GXP US. Próxima atualização: Atualizações adicionais serão fornecidas à medida que mais informações estiverem disponíveis.

2. 10 Eost 2026 da 14:25 UTCresolved

   O problema foi resolvido e o desempenho do Serviço Front-End em Document Understanding retornou aos níveis esperados após o desempenho degradado impactar a UI na Região GXP East US. Impacto: Nenhum impacto contínuo do usuário.

3. 19 Eost 2026 da 06:14 UTCpostmortem

   # # Impacto do cliente Entre 10 de agosto de 2026 às 13:21 UTC e 10 de agosto de 2026 às 14:03 UTC, um subconjunto de clientes experimentou desempenho degradado e timeouts ao acessar a interface de usuário Document Understanding, que proporciona a experiência de design-tempo, na região dos EUA atrasadas. As automações de processamento de documentos não foram afetadas. # # Causa raiz Durante uma implantação manual de uma compilação pré-existente do serviço por trás da interface de usuário Document Understanding para a região EUA atrasada, nosso processo de implantação reatribuiu o identificador de versão para o serviço que está sendo implantado. A interface Document Understanding requer que seus recursos de suporte estejam disponíveis sob o mesmo identificador de versão que o serviço implantado. Como o processo de implantação alterou esse identificador, a interface não conseguiu localizar os recursos necessários, fazendo com que ele se tornasse inacessível ou sem tempo. # # Detecção Tomamos conhecimento da questão momentos após o término da implantação, através da verificação manual como parte da lista de verificação manual de implantação. Um alerta automatizado logo se seguiu, disparado às 13:28 UTC em 10 de agosto de 2026. # # Resposta Depois de identificar o motivo da falha na implantação manual, nossa equipe de engenharia começou a implantar uma atualização corrigida com os recursos necessários disponíveis. Ao mesmo tempo, a equipe de operações foi engajada para realizar um retorno manual da implantação. O retorno foi concluído às 14:03 UTC, restaurando o acesso à experiência de design-tempo. Em 14:11 UTC, publicamos uma atualização de status público indicando desempenho degradado e possíveis timeouts na interface de usuário Document Understanding para a região dos EUA atrasada. Em 14:15 UTC, a atualização corrigida tinha terminado e a interface foi confirmada como implantada com uma nova versão correta e funcionando. Às 14:25 UTC, o incidente foi marcado resolvido e a página de status público foi atualizada para confirmar que o desempenho da interface Document Understanding havia retornado aos níveis esperados. # # Acompanhamento 1. Estamos reduzindo o tempo necessário para restaurar uma versão anterior do serviço, de modo que a recuperação de uma implantação falhada é mais rápida. 2. Estamos fazendo melhorias no processo de implantação manual para evitar uma situação futura, validando a existência dos recursos necessários como pré-requisito.

Traduzido automaticamente da atualização oficial do incidente.

1. 8 Eost 2026 da 11:54 UTCidentified

   We have identified the cause of the outage impacting Uipath Apps is facing outage in Delayed US region and are working on a fix. Impact: Users may continue to be unable to access Uipath Apps and solutions dependent on Uipath Apps. Team is working on service restoration.

2. 8 Eost 2026 da 13:01 UTCidentified

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

3. 8 Eost 2026 da 14:14 UTCidentified

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

4. 8 Eost 2026 da 15:30 UTCidentified

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

5. 8 Eost 2026 da 15:32 UTCmonitoring

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

6. 8 Eost 2026 da 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 Eost 2026 da 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.

1. 6 Eost 2026 da 21:14 UTCresolved

   Between 06-08-2026 10:00 UTC and 06-08-2026 13:00 UTC, some organizations in the US region were unable to complete document ingestion. A small number of search requests in the same region were also slow or timed out. The issue was caused by a capacity constraint affecting ingestion processing in US. Normal performance was restored at 13:00 UTC. We have monitored the affected environments since recovery and confirm the issue is fully mitigated. Ingestion requests that failed during this window were not retried automatically and will need to be re-submitted. No action is required for search.

2. 13 Eost 2026 da 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.