Cronologia delle interruzioni di Uipath

1. 3 settembre 2026 alle ore 15:34 UTCinvestigating

   Stiamo indagando sul problema

2. 3 settembre 2026 alle ore 15:39 UTCidentified

   Il problema è stato individuato, e le opportune misure di mitigazione sono state attuate per affrontarlo.

3. 3 settembre 2026 alle ore 15:47 UTCmonitoring

   Il problema è stato risolto con successo e il servizio è stato completamente restaurato. Il servizio funziona normalmente in questo momento.

4. 3 settembre 2026 alle ore 16:17 UTCresolved

   Il problema è stato risolto con successo e il servizio è stato completamente restaurato. Il servizio funziona normalmente in questo momento.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 4 settembre 2026 alle ore 17:48 UTCresolved

   Il cruscotto Insights di Looker ha sperimentato un problema che ha impedito alle ultime uscite del Maestro, di apparire nel cruscotto Regioni colpite: Stati Uniti, SEA, IND, CA, AUE, JP , UK Timeline incidente Iniziato: 2 settembre 2026 alle 20:00:00 UTC Risolto: 4 settembre 2026 alle 16:30:00 UTC Il problema è stato risolto, e la dashboard di Insights sta visualizzando gli ultimi dati dell'esecuzione del Maestro.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 1 settembre 2026 alle ore 13:49 UTCinvestigating

   Stiamo indagando i rapporti delle prestazioni degradate che influenzano la digitalizzazione e l'estrazione per la comprensione dei documenti e IXP negli Stati Uniti. Impatto: Gli utenti possono sperimentare la lentezza e la mancata comprensione dei documenti operazioni di runtime. I nostri team stanno lavorando per identificare la causa e condividere ulteriori dettagli mentre l'indagine progredisce.

2. 1 settembre 2026 alle ore 14:07 UTCmonitoring

   Abbiamo identificato il problema e applicato una mitigazione. I servizi sono restituiti allo stato sano e stiamo monitorando i servizi.

3. 1 settembre 2026 alle ore 15:06 UTCresolved

   Questo problema è stato completamente risolto e i servizi sono stabili ora. Posteremo più dettagli dell'incidente alla pagina di stato presto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 31 agosto 2026 alle ore 16:55 UTCinvestigating

   Stiamo indagando sul problema.

2. 31 agosto 2026 alle ore 17:07 UTCidentified

   Abbiamo identificato il problema e implementato la correzione necessaria

3. 31 agosto 2026 alle ore 18:24 UTCmonitoring

   Il problema è stato mitigato e il servizio è attualmente operativo. Continueremo a monitorare attentamente la salute del servizio e ad agire in caso di necessità.

4. 31 agosto 2026 alle ore 19:39 UTCresolved

   Il problema è stato mitigato e il servizio è attualmente operativo. Continueremo a monitorare attentamente la salute del servizio e ad agire in caso di necessità.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 28 agosto 2026 alle ore 15:41 UTCidentified

   Il problema è stato identificato, e il team sta attivamente lavorando sulla distribuzione di una correzione. Ci aspettiamo che la distribuzione inizi nelle prossime ore.

2. 28 agosto 2026 alle ore 17:27 UTCmonitoring

   Abbiamo identificato la causa principale delle prestazioni degradate e siamo nel processo di distribuzione di una correzione nelle prossime ore. Colpisce le query collegate in cui l'utente non ha accesso alla cartella originale. La superficie API non è influenzata. L'esportazione tramite CSV può essere utilizzata come soluzione di marcia. Ulteriori aggiornamenti saranno forniti mentre ci muoviamo verso la risoluzione.

3. 28 agosto 2026 alle ore 17:39 UTCidentified

   Abbiamo identificato la causa principale delle prestazioni degradate e siamo nel processo di distribuzione di una correzione nelle prossime ore. Colpisce le query collegate in cui l'utente non ha accesso alla cartella originale. La superficie API non è influenzata. L'esportazione tramite CSV può essere utilizzata come soluzione di marcia. Ulteriori aggiornamenti saranno forniti mentre ci muoviamo verso la risoluzione.

4. 28 agosto 2026 alle ore 20:00 UTCidentified

   La correzione è attualmente in fase di applicazione. Provvederemo a fornire un altro aggiornamento una volta che la distribuzione è stata completata in tutte le regioni interessate.

5. 28 agosto 2026 alle ore 22:57 UTCresolved

   La soluzione è stata implementata con successo in tutte le regioni e abbiamo confermato che il problema è risolto. Il servizio funziona come previsto.

6. 3 settembre 2026 alle ore 08:49 UTCpostmortem

   ## Impatto del cliente Tra il 28 agosto 2026 alle 3:23 UTC e il 28 agosto 2026 alle 10:57 UTC, un sottoinsieme di clienti sperimentato errori durante l'apertura dei pannelli dettagli degli articoli di coda in Orchestrator. Il percorso interessato ha restituito una pagina 404 per le code LINKED quando l'utente non ha avuto accesso alla cartella originale in cui gli elementi sono stati creati. L'impatto ha interessato solo le interazioni dell'interfaccia utente dell'Orchestrator e ha attraversato tutte le regioni che eseguono la versione del software interessato. L'accesso dell'interfaccia di programmazione dell'applicazione dell'Orchestrator non è stato influenzato e l'esportazione dei dati della coda a CSV è stata disponibile come soluzione di lavoro. La durata totale era di circa 7 ore. # L'incidente è stato causato da una regressione nell'interfaccia utente dell'Orchestrator per le code collegate accessibili da altre cartelle. La regressione non ha correttamente gestito il flusso dei dettagli legati-queue quando l'utente richiedente non ha avuto accesso alla cartella originale, che ha causato il pannello dei dettagli dell'elemento di coda per passare a una pagina 404 invece di visualizzare le informazioni attesi. ## Detection Il problema è stato rilevato attraverso un avviso di incidente automatizzato per l'Orchestrator front end il 28 agosto 2026 alle 3:23 UTC. # Alle 15:31 UTC il 28 agosto 2026, il nostro team di ingegneria ha descritto il problema in quanto i clienti non sono in grado di accedere ai pannelli dettagli degli articoli di coda a causa di una regressione. Alle 3:41 UTC, un aggiornamento dello stato pubblico ha confermato che la causa principale era stata identificata, che una correzione era in fase di implementazione, e che l'accesso dell'interfaccia di programmazione dell'applicazione non era influenzato. Alle 17:27 UTC, la portata è stata ridotta alle code collegate in cui l'utente non ha avuto accesso alla cartella originale. Alle 17:29 UTC, il team ha determinato che la correzione iniziale non ha completamente affrontato lo scenario interessato, e una correzione corretta è stata sviluppata. Alle 17:30 UTC, lo scenario interessato è stato riprodotto e la correzione corretta è stata convalidata localmente. Alle 17:39 UTC, un aggiornamento della pagina di stato documentato CSV esportazione come soluzione di lavoro. La distribuzione della correzione corretta è proseguita in tutte le regioni colpite. Alle 10:50 UTC, la correzione è stata confermata schierata ovunque. Alle 10:57 UTC, l'incidente è stato risolto e la pagina di stato è stato aggiornato per confermare che il servizio è stato operativo come previsto. ## Seguilo # Le azioni formali di follow-up sono state tracciate attraverso il processo di revisione post-incidente avviato alla risoluzione. ## Elementi d'azione - Ampliamento dei nostri casi di test automatizzati per includere questo scenario, e altri scenari simili relativi a oggetti collegati o scenari cross-folder. - Garantire che possiamo disattivare in modo sicuro qualsiasi cambiamento tramite una bandiera per un tempo di risposta più veloce.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 27 agosto 2026 alle ore 17:16 UTCinvestigating

   Stiamo indagando sui rapporti dei registri dei robot mancanti nella regione degli Stati Uniti. I nostri team stanno lavorando per identificare la causa e condividere ulteriori dettagli mentre l'indagine progredisce.

2. 27 agosto 2026 alle ore 18:53 UTCidentified

   Abbiamo identificato che l'ingestione dei registri robot è stata ritardata. I registri dei robot stanno raggiungendo i dati dal vivo e stiamo monitorando il recupero.

3. 27 agosto 2026 alle ore 20:31 UTCmonitoring

   I registri stanno ora populando come previsto in tempo reale e continueremo a monitorare l'applicazione.

4. 27 agosto 2026 alle ore 21:57 UTCresolved

   Il problema è stato risolto e i registri stanno populando come previsto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 25 agosto 2026 alle ore 09:41 UTCidentified

   Abbiamo identificato un problema che riguarda la funzione Solution Deployment in Studio Web nella regione del Giappone, dove le implementazioni delle soluzioni potrebbero fallire. Una soluzione è stata preparata e verrà rimossa a breve. Forniremo ulteriori aggiornamenti in quanto ulteriori informazioni diventano disponibili.

2. 25 agosto 2026 alle ore 09:47 UTCmonitoring

   La soluzione è stata implementata con successo nella regione del Giappone, e il problema è stato mitigato. Stiamo monitorando attentamente il servizio per garantire che Solution Deployment continui a funzionare come previsto e fornirà ulteriori aggiornamenti, se necessario.

3. 25 agosto 2026 alle ore 10:12 UTCresolved

   Il problema è stato risolto e Solution Deployment in Studio Web funziona come previsto nella regione del Giappone. Non è stato osservato alcun ulteriore impatto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 25 agosto 2026 alle ore 03:58 UTCinvestigating

   Stiamo indagando su un problema che riguarda i clienti che utilizzano Insights nella regione di Singapore, dove le dashboard possono non caricare e visualizzare errori di timeout. I nostri team stanno lavorando per identificare la causa principale e forniranno ulteriori aggiornamenti come ulteriori informazioni diventano disponibili.

2. 25 agosto 2026 alle ore 04:37 UTCmonitoring

   Il problema è stato mitigato, e stiamo monitorando attentamente il servizio Insights nella regione di Singapore per garantire che le dashboard continuino a caricare come previsto.

3. 25 agosto 2026 alle ore 04:53 UTCresolved

   Il problema è stato risolto, e il servizio Insights nella regione di Singapore è operativo come previsto. Non è stato osservato alcun ulteriore impatto.

4. 4 settembre 2026 alle ore 11:46 UTCpostmortem

   ## Impatto del cliente Tra il 25 agosto 2026 alle 3:42 del UTC e il 25 agosto 2026 alle 4:53 del UTC, i clienti che utilizzano Insights nella regione di Singapore hanno sperimentato guasti di carico Insights dashboard. Gli utenti interessati hanno visto le pagine del cruscotto tempo fuori o non caricare, e gli errori del server sono stati osservati per le relative richieste di servizio. L'impatto principale è stato quello di Insights accesso cruscotto, tra cui grafici e avvisi. Un relativo servizio backend ha anche restituito gli errori del server durante l'incidente, ma l'accesso del cruscotto è stato recuperato prima della risoluzione finale. # L'incidente è stato attribuito a una disgregazione regionale di servizio Microsoft a Singapore che interessa l'infrastruttura utilizzata dal servizio Insights. Durante l'interruzione, il servizio Insights non è stato in grado di servire in modo affidabile le richieste del cruscotto, con conseguente timeout di richiesta e errori del server. Nessun cambiamento è stato fatto dalla nostra parte. Il servizio recuperato come la disgregazione regionale Microsoft è stato risolto, e Microsoft successivamente ha riferito un problema di servizio regionale di Singapore sulla sua pagina di stato. Un'analisi formale delle cause radice è stata richiesta da Microsoft per confermare il meccanismo di guasto specifico e identificare eventuali ulteriori misure preventive o di mitigazione. ## Detection Il monitoraggio automatizzato della salute per il servizio Insights ha rilevato il problema al 25 agosto 2026 alle 3:42 am UTC. L'impatto del cliente è stato confermato sul ponte di risposta poco dopo il rilevamento. # A agosto 25, 2026 a 3:58 am UTC, abbiamo postato un aggiornamento di stato pubblico notando che le dashboard di Insights nella regione di Singapore potrebbero non caricare e visualizzare errori di timeout. Durante la risposta, il nostro team di ingegneria ha verificato gli errori del server nel monitoraggio automatizzato, ha tentato di accedere alla diagnostica del servizio, e ha iniziato una procedura di recupero sull'infrastruttura sottostante. Al 25 agosto 2026 alle 4:01 UTC, il servizio Insights recuperato mentre la procedura di recupero era in corso, e il caricamento del cruscotto è stato convalidato attraverso più account di test. Al 25 agosto 2026 alle 4:37 am UTC, abbiamo spostato l'incidente al monitoraggio dopo aver confermato dashboard caricati con successo. Un relativo servizio di backend recuperato al 25 agosto 2026 alle 4:49 UTC, e l'incidente è stato risolto al 25 agosto 2026 alle 4:53 UTC. ## Seguilo # 1. Richiedi un'analisi delle cause di root da Microsoft per la disgregazione regionale di Singapore che interessa il problema di caricamento delle dashboard di insights.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 25 agosto 2026 alle ore 03:44 UTCinvestigating

   Stiamo indagando su un problema che riguarda i clienti che utilizzano la funzionalità Extended OCR nel servizio Document Understanding nella regione di Singapore. I nostri team stanno lavorando per identificare la causa principale e forniranno ulteriori aggiornamenti come ulteriori informazioni diventano disponibili.

2. 25 agosto 2026 alle ore 04:04 UTCmonitoring

   Il problema è stato mitigato, e stiamo monitorando attentamente il servizio per assicurarlo continua a funzionare come previsto. Forniremo ulteriori aggiornamenti in quanto ulteriori informazioni diventano disponibili.

3. 25 agosto 2026 alle ore 04:59 UTCresolved

   Il problema è stato risolto e il servizio funziona come previsto. Non è stato osservato alcun ulteriore impatto.

4. 27 agosto 2026 alle ore 03:42 UTCpostmortem

   ## Impatto del cliente Il 25 agosto 2026, le richieste di OCR estesa nel servizio di Document Understanding non sono riuscite con 500 codice di stato nella regione di Singapore per circa 33 minuti, tra 03:08 e 03:41 UTC. La causa era una disgregazione di servizio regionale Microsoft a Singapore. Tutte le altre funzionalità di Document Understanding non sono state influenzate e nessun'altra regione è stata influenzata. # Il fallimento è stato attribuito a una disgregazione regionale di servizio Microsoft a Singapore che interessa le risorse utilizzate dalla capacità di Extended OCR. Non sono state apportate modifiche da parte nostra, e Microsoft ha successivamente aggiornato la propria pagina di stato per riflettere un problema regionale di Singapore. Un'analisi formale delle cause radice è stata richiesta da Microsoft. ## Detection Un avviso automatizzato per il servizio Document Understanding licenziato il 25 agosto 2026 alle 3:13 UTC. L'avviso è stato riconosciuto prontamente, e l'incidente è stato dichiarato cliente-impatto entro pochi minuti. # L'ingegnere on-call ha portato l'impatto alla regione di Singapore. I Responders hanno escluso un recente aggiornamento del servizio come causa, come lo stesso aggiornamento era stato distribuito ad altre regioni senza un impatto comparabile, che ha indicato un fallimento della dipendenza regionale al di fuori della nostra infrastruttura. Poiché il fallimento ha avuto origine in un servizio Microsoft a monte, nessuna azione mitigante è stata disponibile o richiesta sul lato UiPath. Le richieste hanno cominciato a succedere di nuovo a 03:41 UTC come la dipendenza Microsoft recuperato. I risponditori hanno tenuto l'incidente aperto per verificare il recupero sostenuto: dieci minuti di traffico pulito sono stati confermati alle 03:51 UTC, l'incidente si è spostato al Monitoraggio alle 04:04 UTC, ed è stato risolto alle 04:59 UTC dopo la stabilità continuata senza ulteriori fallimenti. ## Seguilo # 1. Richiesto un'analisi della causa principale da Microsoft per la disgregazione regionale di Singapore che interessa le dipendenze di OCR estesa, tra cui come può essere evitata la ricorrenza.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 24 agosto 2026 alle ore 10:43 UTCidentified

   Abbiamo identificato la causa di un problema che colpisce un piccolo numero di clienti che utilizzano UiPath Apps autorizzato dal servizio Web Studio in più regioni. I nostri team sono pronti con una soluzione, e la distribuzione sta per iniziare attraverso le regioni colpite. Continueremo a monitorare l'implementazione e fornire ulteriori aggiornamenti man mano che la correzione ha effetto.

2. 24 agosto 2026 alle ore 11:30 UTCmonitoring

   La soluzione è stata implementata con successo in tutte le regioni interessate, e il problema è stato mitigato. Stiamo monitorando attentamente il servizio per garantire che la correzione continui a eseguire come previsto e fornirà ulteriori aggiornamenti, se necessario.

3. 24 agosto 2026 alle ore 11:55 UTCresolved

   Il problema è stato risolto e il servizio funziona come previsto. Non è stato osservato alcun ulteriore impatto.

4. 1 settembre 2026 alle ore 11:47 UTCpostmortem

   ## Impatto del cliente Tra il 19 agosto 2026 alle 2:33 UTC e il 24 agosto 2026 alle 11:30 UTC, un sottoinsieme di clienti non poteva caricare i progetti di UiPath Apps autorizzati da Studio Web. I clienti interessati hanno sperimentato la completa indisponibilità dei progetti Apps piuttosto che la lentezza o le prestazioni degradate. L'impatto è stato limitato a una piccola serie di clienti, il cui servizio Apps è stato ospitato nella regione del Giappone. La durata totale dell'impatto del cliente è stata di circa 4 giorni e 21 ore. # La causa principale era un errore di distribuzione tra Studio Web e UiPath Apps. Il 19 agosto 2026, Studio Web ha ricevuto un aggiornamento programmato nella regione UE che includeva un aggiornamento quadro. L'aggiornamento corrispondente delle app UiPath contenente l'aggiornamento del framework non era ancora stato distribuito all'unità di scala del Giappone. Un precedente aggiornamento delle app che era già compatibile con la nuova versione quadro era stato distribuito a tutte le regioni tranne il Giappone, dove il dispiegamento era stato differito a causa di motivi non correlati. Di conseguenza, la regione del Giappone era ancora in esecuzione una vecchia versione Apps che non era compatibile con l'aggiornamento di Studio Web. ## Detection Il problema è stato segnalato da un cliente attraverso il loro team di account UiPath il 24 agosto 2026 a 9:36 am UTC. Un incidente è stato aperto alle 10:21 di UTC, e un incidente di pagina di stato pubblico è stato dichiarato entro un minuto. Il monitoraggio automatizzato esistente non ha rilevato il problema perché convalida le combinazioni di distribuzione abbinate; migliorare il rilevamento per configurazioni miste fa parte del nostro piano di follow-up. # Nel giro di pochi minuti di apertura dell'incidente, abbiamo identificato l'errore di distribuzione come causa principale e abbiamo deciso di accelerare l'implementazione del corrispondente UiPath Apps aggiornamento a tutte le regioni colpite, allineando Apps con la versione di Studio Web già essere servita ai clienti colpiti. Alle 10:43 di UTC, abbiamo postato un aggiornamento dello stato pubblico confermando la causa era stata identificata e che la correzione era stata implementata. Alle 10:52 UTC, il dispiegamento era in corso per le restanti regioni, con diverse regioni già complete. Alle 11:30 del UTC, abbiamo confermato che la correzione era stata dispiegata in tutte le regioni interessate e ha segnato l'incidente mitigato. Alle 11:55 del UTC, dopo il monitoraggio non ha mostrato ulteriore impatto, l'incidente è stato risolto. ## Seguilo # 1. Aggiungi all'avviso automatizzato sulla telemetria di produzione per rilevare guasti di carico delle app correlati alla versione di Studio Web. 2. Esecuzione di monitoraggio sintetico che carica regolarmente un progetto Apps autorizzato da Studio Web attraverso configurazioni e avvisi dei clienti rappresentativi sul fallimento. 3. Regolare il sequenziamento di rilascio per i cambiamenti strettamente accoppiati Studio Web e Apps in modo che gli aggiornamenti delle app dipendenti siano completamente dispiegati a tutte le regioni prima che la nuova esperienza di Studio Web raggiunga il traffico dei clienti.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 21 agosto 2026 alle ore 12:37 UTCmonitoring

   Una correzione è stata implementata per la classificazione e l'estrazione del documento di impatto del problema per la comprensione dei documenti negli Stati Uniti, e stiamo monitorando i risultati.

2. 21 agosto 2026 alle ore 13:36 UTCresolved

   È stato risolto il problema della classificazione e dell'estrazione dei documenti per la comprensione dei documenti nella regione degli Stati Uniti. Dopo un periodo di monitoraggio, il servizio viene confermato sano e funziona normalmente.

3. 27 agosto 2026 alle ore 03:46 UTCpostmortem

   ## Impatto del cliente Tra il 21 agosto 2026 alle 11:05 UTC e il 21 agosto 2026 alle 12:18 UTC, un sottoinsieme di clienti sperimentato fallito Document Understanding operazioni, compresa la classificazione dei documenti, l'estrazione e la digitalizzazione. La durata stimata dell'interruzione parziale era di 48 minuti. L'impatto è stato limitato ai clienti che utilizzano Document Understanding nella regione degli Stati Uniti. # L'incidente è stato causato dalla configurazione del failover del database di archiviazione di Document Understanding che entra in uno stato rotto durante un'operazione preventiva di scale-up del database. La scala-up è stata avviata dopo che il database si è avvicinato al suo limite di archiviazione. Durante l'operazione, il database secondario non poteva essere scalato, il tentativo di rimozione dalla configurazione failover non è riuscito, e il provider della piattaforma di database ha dovuto rompere il link di replica. Questo ha lasciato la configurazione di failover in uno stato non disponibile temporaneo, causando i servizi di storage e runtime che dipendono da quel database per fallire le richieste. ## Detection L'incidente è stato rilevato attraverso un avviso automatizzato per i servizi di Document Understanding, che è stato riconosciuto il 21 agosto 2026 alle 12:10 UTC. # Prima di dichiarare l'incidente di impatto del cliente, la scala-up del database primario è stata completata e il supporto del provider della piattaforma di database è stato impegnato per il problema del database secondario. Dopo la rottura della configurazione del failover, abbiamo esplorato il reindirizzamento della connessione di servizio, ma non abbiamo potuto identificare un percorso sicuro e immediato per farlo data la configurazione attuale del servizio. Il servizio è stato ripristinato eliminando il database secondario malsano e ricreando la configurazione del failover. Entro il 21 agosto 2026 alle 12:37 UTC, la fissazione era stata implementata e il monitoraggio era in corso. Alle 13:00 UTC, il monitoraggio ha confermato che il servizio era sano, e l'incidente è stato risolto. ## Seguilo # 1. Richiedere un'analisi delle cause di root dal provider della piattaforma di database per determinare il motivo per cui il database secondario non potrebbe essere scalato e perché la correzione di configurazione di failover richiedesse la replica di rottura. 2. Aggiornare le soglie di avviso di archiviazione del database e il routing così gli avvisi sono assegnati e agito in precedenza, tra cui un avviso di minore gravità al 75% di utilizzo e un avviso di maggiore gravità all'85% di utilizzo.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 19 agosto 2026 alle ore 16:34 UTCinvestigating

   Stiamo indagando su un problema che può influenzare alcuni clienti che utilizzano Claude Sonnet 4.6 negli agenti nella regione degli Stati Uniti. Il nostro team di ingegneria sta lavorando attivamente per capire il problema e condividerà ulteriori aggiornamenti come ulteriori informazioni diventano disponibili.

2. 19 agosto 2026 alle ore 16:40 UTCmonitoring

   Abbiamo mitigato il problema. Il nostro team di ingegneria è attivamente mattina e condividerà ulteriori aggiornamenti come ulteriori informazioni diventano disponibili.

3. 19 agosto 2026 alle ore 16:42 UTCmonitoring

   Abbiamo mitigato il problema. Il nostro team di ingegneria sta monitorando attivamente e condividerà ulteriori aggiornamenti come ulteriori informazioni diventano disponibili.

4. 19 agosto 2026 alle ore 16:55 UTCresolved

   Il problema è stato risolto.

5. 31 agosto 2026 alle ore 12:41 UTCpostmortem

   ## Impatto del cliente Tra il 19 agosto 2026 alle 1:36 UTC e il 19 agosto 2026 alle 3:53 UTC, un sottoinsieme di clienti ha ricevuto errori quando si utilizza Claude Sonnet 4.6 negli agenti. L'impatto durò circa 2 ore e 17 minuti. L'impatto è stato ai clienti che utilizzano Agenti nella regione degli Stati Uniti. Sono stati osservati anche errori per Claude Opus 4.6 e Claude Opus 4.5, che vengono utilizzati a volume inferiore. --- # Causa radice # Nell'ambito di una migrazione pianificata delle infrastrutture, abbiamo spostato il servizio della piattaforma che tratta le richieste dei modelli per gli agenti su un nuovo sistema di distribuzione della configurazione, regione per regione. La nuova fonte di configurazione mancava le voci di routing per tre modelli Claude Sonnet 4.6, Claude Opus 4.6, e Claude Opus 4.5. Senza tali voci, il servizio non poteva risolvere una destinazione valida per le richieste a quei modelli, e li ha rifiutati con errori. Altri modelli non sono stati colpiti e hanno continuato a servire normalmente durante tutto. --- ## Detection Il problema è stato rilevato attraverso escalation del cliente il 19 agosto 2026 alle 2:55 pm UTC — circa 1 ora e 19 minuti dopo la prima richiesta interessata. Il nostro team di ingegneria ha affrontato il problema a specifici modelli Claude e ha iniziato l'indagine. La comunicazione di stato pubblico è iniziata alle 3:08 UTC. Il nostro monitoraggio degli avvisi si basa sui tassi di errore aggregati. Sebbene quasi tutte le richieste ai tre modelli interessati fossero inadeguate, quei modelli rappresentavano una piccola parte del traffico complessivo nella regione, quindi il segnale aggregato non ha oltrepassato le nostre soglie di avviso e il problema non è stato sollevato automaticamente. Questo è il gap di rilevamento affrontato nel follow-up qui sotto. --- # Alle 3:25 UTC, la sorgente di configurazione incompleta è stata identificata come la causa, e è stata avviata una correzione. Alle 3:47 UTC, l'implementazione della correzione era in corso, e il servizio è stato attivamente monitorato come il cambiamento è andato fuori. Entro le 3:59 UTC, i registri di servizio hanno confermato il problema è stato mitigato, e alle 16:00 UTC il tasso di guasto è stato confermato al 0%. L'incidente è stato segnato mitigato alle 16:40 UTC, e la risoluzione completa è stata dichiarata alle 16:55 UTC dopo il monitoraggio continuato e la conferma del cliente che il servizio stava lavorando come previsto. --- ## Follow-Up La migrazione infrastrutturale è stata completata in tutte le regioni e la configurazione di routing ora si disegna da un'unica fonte, rimuovendo il errore che ha causato questo incidente in modo che non possa ripetersi. Vengono introdotti controlli automatizzati per verificare continuamente ogni modello supportato in ogni regione, quindi un modello non disponibile viene rilevato e avvisato immediatamente, anche nelle regioni a basso traffico.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 18 agosto 2026 alle ore 17:54 UTCinvestigating

   Stiamo indagando i rapporti di un'estrazione che colpisce i guasti nelle valutazioni di espressione relative ai parametri di output di HITL per Asgentic Orchestratron negli utenti comunitari in Europa. Impatto: gli utenti potrebbero non essere in grado di completare le attività HITL Prossimo aggiornamento: I nostri team stanno lavorando per capire la causa e la portata e condivideranno gli aggiornamenti come disponibile.

2. 18 agosto 2026 alle ore 20:31 UTCidentified

   Abbiamo individuato la causa di una valutazione dell'espressione d'impatto dell'outage relativa ai parametri di output dell'attività HITL per l'Orchestrazione Agentica negli utenti comunitari in Europa. Impatto: Gli utenti sperimenteranno i guasti quando hanno un'espressione utilizzando il parametro di uscita dell'attività HITL. Prossimo aggiornamento: I nostri team stanno lavorando per capire la causa e la portata e condivideranno gli aggiornamenti come disponibile.

3. 18 agosto 2026 alle ore 21:45 UTCidentified

   Abbiamo identificato la soluzione e la risoluzione è in corso. Prossimo aggiornamento: I nostri team stanno lavorando alla correzione e condivideranno gli aggiornamenti come disponibile.

4. 18 agosto 2026 alle ore 22:53 UTCmonitoring

   Abbiamo implementato la correzione e stiamo monitorando la risoluzione. Prossimo aggiornamento: I nostri team stanno monitorando la risoluzione e condivideranno gli aggiornamenti come disponibile.

5. 18 agosto 2026 alle ore 23:25 UTCresolved

   L'interruzione è stata risolta e l'Orchestrazione Agentica è pienamente operativa. Impatto: nessun impatto utente in corso.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 18 agosto 2026 alle ore 12:08 UTCidentified

   Abbiamo identificato la causa principale di un problema in Studio Web dove la schermata di configurazione delle risorse per il cambiamento degli attributi delle risorse non è il caricamento. Stiamo implementando una soluzione.

2. 18 agosto 2026 alle ore 13:05 UTCidentified

   La distribuzione della correzione è in corso. Forniremo ulteriori aggiornamenti mentre la distribuzione progredisce.

3. 18 agosto 2026 alle ore 14:06 UTCidentified

   La fissazione è stata verificata e viene presentata in tutte le regioni restanti. Stiamo monitorando la distribuzione e il recupero. Grazie per la pazienza.

4. 18 agosto 2026 alle ore 17:03 UTCidentified

   Il rollout sta progredendo come previsto nelle altre regioni. Continuiamo a monitorare la distribuzione. Grazie per la pazienza.

5. 18 agosto 2026 alle ore 18:12 UTCmonitoring

   Il rollout sta progredendo come previsto nelle altre regioni. Continuiamo a monitorare la distribuzione. Grazie per la pazienza.

6. 18 agosto 2026 alle ore 19:05 UTCresolved

   Il rollout è completato e il problema deve essere risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 18 agosto 2026 alle ore 05:32 UTCinvestigating

   Stiamo indagando su un problema che riguarda i conti comunitari in cui le entità appena create possono richiedere circa un'ora per apparire in Studio Web. Nessun dato è perso, e le entità esistenti non sono influenzate.

2. 18 agosto 2026 alle ore 06:48 UTCinvestigating

   Continuiamo a indagare sul problema e stiamo lavorando per identificare la causa principale e ripristinare i tempi di elaborazione normali.

3. 18 agosto 2026 alle ore 08:44 UTCinvestigating

   Continuiamo a indagare sul problema che riguarda un sottoinsieme di inquilini in Europa, negli Stati Uniti e in Giappone, dove le entità appena create possono richiedere più tempo del previsto per apparire in Studio Web. Nessun dato è perso, e le entità esistenti non sono influenzate.

4. 18 agosto 2026 alle ore 09:37 UTCidentified

   Abbiamo individuato la causa e stiamo lavorando su una risoluzione per la questione che riguarda un sottoinsieme di inquilini in Europa, negli Stati Uniti e in Giappone. Grazie per la pazienza.

5. 18 agosto 2026 alle ore 11:19 UTCmonitoring

   Il problema è stato mitigato, e ci aspettiamo tempi di elaborazione per tornare alla normalità a breve. Stiamo monitorando il recupero da vicino. Grazie per la pazienza.

6. 18 agosto 2026 alle ore 11:57 UTCresolved

   Il problema è stato risolto e il tempo di elaborazione è tornato alla normalità. Grazie per la pazienza.

7. 27 agosto 2026 alle ore 03:51 UTCpostmortem

   ## Impatto del cliente Tra il 18 agosto 2026 alle 5:11 am UTC e il 18 agosto 2026 alle 11:57 am UTC, entità appena create in un sottoinsieme di inquilini UiPath Cloud potrebbe richiedere più tempo di quanto previsto per apparire in Studio Web. Al momento della valutazione iniziale, le entità appena create appaiono con un ritardo di circa un'ora. I clienti in Europa, Stati Uniti e Giappone sono stati colpiti. La creazione di Entity stessa ha continuato con successo, nessun dato è stato perso, e le entità esistenti non sono state influenzate. # Il problema è stato causato da un volume insolitamente elevato di richieste di creazione di attività da un inquilino. Tali richieste hanno generato più eventi rispetto al nostro servizio di indicizzazione delle entità backend potrebbero elaborare allo stesso ritmo, creando un backlog nella coda di elaborazione degli eventi. Poiché Studio Web si basa su questo servizio per visualizzare le entità appena create, nuove entità sono apparse solo dopo che il backlog è stato elaborato. ## Detection Il problema è stato identificato dal nostro team di ingegneria da avviso di latenza di elaborazione di entità, e un incidente è stato dichiarato a 5:11 am UTC il 18 agosto 2026. Entro le 5:23 del UTC, l'analisi ha confermato che l'ultima entità elaborata era circa un'ora indietro. # A 5:32 am UTC, abbiamo postato un primo aggiornamento del cliente notando la visibilità ritardata per le entità appena create in Studio Web. Entro le 6:07 del UTC, l'indagine ha identificato insolitamente alto traffico di asset-creation da un inquilino, e alle 7:03 del UTC, abbiamo regolato le risorse del database per il servizio interessato per aiutare il recupero di elaborazione. Alle 7:59 UTC, la fonte del volume di alta richiesta aveva smesso di inviare richieste, e la coda ha cominciato a drenare. Alle 9:59 di UTC, abbiamo iniziato un processo di sincronizzazione dei dati per l'inquilino interessato, e alle 10:31 di UTC, abbiamo rimosso gli eventi problematici in coda in modo che l'elaborazione normale potrebbe raggiungere più velocemente. La profondità di queue è diminuita da 95.000 articoli a 8:34 am UTC a 1.000 articoli a 11:44 am UTC. L'incidente è stato segnato mitigato alle 11:19 am UTC dopo l'elaborazione recuperato sostanzialmente, e risolto alle 11:57 am UTC dopo il tempo di elaborazione restituito alla normalità. ## Seguilo # Sincronizzazione dei dati per l'inquilino interessato e monitoraggio dell'ingestione fino a quando i dati dell'inquilino non sono confermati coerenti. Migliorare la gestione delle entità nel backend indicizzazione in modo che il backlog non si accumula a questo tasso.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 14 agosto 2026 alle ore 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 agosto 2026 alle ore 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 agosto 2026 alle ore 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 agosto 2026 alle ore 10:58 UTCresolved

   Una tempesta di richieste su una funzione di modello raramente utilizzata in IXP Communications Mining ha causato un loop di riprovazione per bloccare le richieste sincrono nella più ampia API IXP. Ciò ha causato le richieste di fallire con 500 come lavoratori erano occupati con richieste di lunga durata. Ridimensionamento automatico rapidamente raggiunto la sua capacità massima e la risoluzione è stata fatta solo applicando una correzione di codice che ha introdotto timeout rigorosi alla richiesta API contributo. La tempesta di richiesta è iniziata intorno 15:10 UTC e ha rilevato un 15:15 UTC da allarmi automatici. La risoluzione è stata confermata intorno alle 18:15 UTC. L'incidente è stato inizialmente erroneamente attribuito solo al cliente che fa la tempesta di richieste, ma in seguito è stato scoperto di aver colpito una vasta gamma di utenti. Impatto totale limitato a una manciata di utenti negli Stati Uniti.

2. 18 agosto 2026 alle ore 21:25 UTCpostmortem

   ## Impatto del cliente Il 12 agosto 2026, tra le 15:10 e le 18:15 UTC, gli utenti di Communications Mining (IXP) nella regione degli Stati Uniti hanno sperimentato errori di richiesta intermittente. L'incidente è stato confinato a una delle unità di distribuzione della regione, dove gli utenti su di esso hanno visto fallimenti in esplosioni di cinque a dieci minuti, con fino al 5–7% delle loro richieste fallendo con errori 5xx al picco. Tra le esplosioni il servizio operato normalmente, le richieste recuperate generalmente sono succedute, e nessun dato è stato perso. # Causa radice # Una tempesta di richieste ad una caratteristica API raramente utilizzata che calcola le previsioni machine-learning su richiesta coincise con la riqualifica ripetuta del modello richiesto. Ogni riqualificazione delle previsioni cache invalidate, trasformando ogni richiesta in un calcolo multiminuto. L'API non ha messo alcun limite di tempo su quanto una richiesta potrebbe aspettare questo calcolo, in modo che queste richieste di lunga durata occupassero progressivamente tutte le capacità di elaborazione delle richieste, causando richieste non correlate a fallire. Ridimensionamento automatico raggiunto la sua capacità massima rapidamente e non poteva compensare. ## Detection Il monitoraggio automatizzato ha rilevato i guasti a 15:15 UTC, circa cinque minuti dopo l'impatto iniziato, e ha chiamato l'ingegnere on-call. L'incidente è stato inizialmente attribuito solo al cliente che genera la tempesta di richiesta, ma i rapporti dei clienti e ulteriori indagini hanno mostrato un più ampio insieme di utenti è stato colpito durante i fallimenti. # L'ingegnere on-call ha tracciato i fallimenti all'attesa inesauribile nel percorso di previsione on-demand. La capacità di servizio è stata ripetutamente ripristinata dalla sostituzione automatica delle istanze, mentre è stata sviluppata una correzione di codice. La correzione è un timeout rigoroso sulla richiesta di contributo in modo da non compromettere velocemente le altre richieste, e è stato distribuito alla regione interessata a circa 18:00 UTC, e la risoluzione è stata confermata alle 18:15 UTC. ## Follow-Up 1. La rigida correzione di timeout e di carico è stata resa permanente e rilasciata a tutte le regioni (completo il 13 agosto 2026). 2. Valutare i limiti per-client sul calcolo della previsione on-demand in modo che l'utilizzo di un singolo client non possa degradare l'API condivisa.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 10 agosto 2026 alle ore 14:11 UTCinvestigating

   Stiamo indagando sulle prestazioni degradate che influenzano i Servizi di Front-End in Comprensione dei documenti in tutta la GXP East US Region. Impatto: Gli utenti possono notare i timeout quando si accede all'interfaccia utente negli Stati Uniti GXP. Prossimo aggiornamento: Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

2. 10 agosto 2026 alle ore 14:25 UTCresolved

   Il problema è stato risolto e l'esecuzione del Servizio Front-End in Document Understanding è tornato ai livelli attesi dopo che le prestazioni degradate hanno colpito l'interfaccia utente nella GXP East US Region. Impatto: nessun impatto utente in corso.

3. 19 agosto 2026 alle ore 06:14 UTCpostmortem

   ## Impatto del cliente Tra il 10 agosto 2026 alle 13:21 UTC e il 10 agosto 2026 alle 14:03 UTC, un sottoinsieme di clienti sperimentato prestazioni e timeout degradati quando si accede all'interfaccia utente di Document Understanding, che fornisce l'esperienza di progettazione-tempo, nella regione degli Stati Uniti ritardati. Le automazioni di elaborazione dei documenti non sono state influenzate. # Durante una distribuzione manuale da una costruzione preesistente del servizio dietro l'interfaccia utente di Document Understanding alla regione degli Stati Uniti ritardati, il nostro processo di distribuzione ha riassegnato l'identificatore di versione per il servizio in essere distribuito. L'interfaccia Document Understanding richiede che le sue risorse di supporto siano disponibili sotto lo stesso identificatore di versione del servizio distribuito. Poiché il processo di distribuzione ha cambiato questo identificatore, l'interfaccia non poteva individuare le risorse richieste, causando che diventasse inaccessibile o fuori tempo. ## Detection Siamo diventati consapevoli dei momenti di emissione dopo che l'implementazione è stata terminata, attraverso la verifica manuale come parte della lista di controllo di distribuzione manuale. Un avviso automatizzato poco dopo, innescato a 13:28 UTC il 10 agosto 2026. # Dopo aver individuato il motivo per il fallimento della distribuzione manuale, il nostro team di ingegneri ha iniziato a implementare un aggiornamento corretto con le risorse necessarie disponibili. Allo stesso tempo, il team operativo è stato impegnato per eseguire un rollback manuale della distribuzione. Il rollback è stato completato alle 14:03 UTC, ripristinando l'accesso all'esperienza di design-time. A 14:11 UTC, abbiamo pubblicato un aggiornamento di stato pubblico che indica le prestazioni degradate e possibili timeout nell'interfaccia utente di Document Understanding per la regione degli Stati Uniti ritardati. Entro le 14:15 UTC, l'aggiornamento corretto era completato e l'interfaccia è stata confermata come implementata con una nuova versione corretta e di lavoro. Alle 14:25 UTC, l'incidente è stato risolto e la pagina dello stato pubblico è stata aggiornata per confermare che le prestazioni dell'interfaccia di Document Understanding erano tornate ai livelli previsti. ## Seguilo # 1. Stiamo riducendo il tempo necessario per ripristinare una versione precedente del servizio, in modo che il recupero da una distribuzione fallita è più veloce. 2. Stiamo facendo miglioramenti al processo di distribuzione manuale per prevenire una situazione futura, convalidando l'esistenza delle risorse richieste come prerequisito.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 8 agosto 2026 alle ore 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 agosto 2026 alle ore 13:01 UTCidentified

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

3. 8 agosto 2026 alle ore 14:14 UTCidentified

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

4. 8 agosto 2026 alle ore 15:30 UTCidentified

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

5. 8 agosto 2026 alle ore 15:32 UTCmonitoring

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

6. 8 agosto 2026 alle ore 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 agosto 2026 alle ore 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 agosto 2026 alle ore 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 agosto 2026 alle ore 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.