Cronologia delle interruzioni di Circle Ci

1. 4 settembre 2026 alle ore 15:16 UTCinvestigating

   Abbiamo rilevato problemi di rete che interessano la nostra infrastruttura Mac. Stiamo indagando e forniremo aggiornamenti a breve. I clienti possono sperimentare queuing durante questo periodo.

2. 4 settembre 2026 alle ore 15:43 UTCidentified

   Abbiamo identificato il problema di rete con il nostro provider di infrastrutture Mac, e stiamo lavorando con loro per risolvere il problema. Stiamo iniziando a vedere un po' di recupero, ma ci aspettiamo che i clienti vedano ancora qualche coda. Ci aggiorneremo presto.

3. 4 settembre 2026 alle ore 16:19 UTCmonitoring

   Il nostro provider di infrastrutture Mac ha applicato una correzione a questo problema di rete e stiamo vedendo i tempi di coda tornare alla normalità. Continueremo a tenere d'occhio le cose per un po'. Ci aggiorneremo presto.

4. 4 settembre 2026 alle ore 16:55 UTCresolved

   Non abbiamo visto alcun ulteriore impatto ai tempi di coda e tutto è tornato alla normalità. Apprezziamo la vostra pazienza mentre abbiamo lavorato per risolvere e monitorare questo problema.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 26 agosto 2026 alle ore 15:43 UTCidentified

   I clienti possono sperimentare errori intermittenti quando si visualizza l'utilizzo del piano UIs o chiamando API di utilizzo del piano. Abbiamo identificato il problema e stiamo lavorando attivamente per mitigare questi errori.

2. 26 agosto 2026 alle ore 16:04 UTCmonitoring

   Abbiamo mitigato il problema con le API di utilizzo del piano e le pagine pertinenti nell'interfaccia utente stanno caricando correttamente.

3. 26 agosto 2026 alle ore 16:10 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 25 agosto 2026 alle ore 23:20 UTCresolved

   Tra 19:49 UTC e 21:07 UTC il 25 agosto 2026, i clienti che tentano di accedere a CircleCI utilizzando GitHub non sono stati in grado di firmare, e ha ricevuto un errore da GitHub affermando che l'URL di callback è stato invalido. I clienti che erano già registrati non erano interessati. Il problema è stato risolto e GitHub login funziona normalmente. Vi ringraziamo per la vostra pazienza mentre il nostro team ha lavorato per la realizzazione di una soluzione.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 17 agosto 2026 alle ore 21:06 UTCidentified

   La causa del problema è stata identificata e siamo al lavoro a risolverlo.

2. 17 agosto 2026 alle ore 21:36 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

3. 17 agosto 2026 alle ore 21:37 UTCresolved

   I dati di controllo sono buoni ancora una volta. Grazie per la pazienza.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 17 agosto 2026 alle ore 14:04 UTCidentified

   GitHub ha segnalato un incidente che sta influenzando la pipeline CircleCI attivando e accedendo: https://www.githubstatus.com/incidents/zkxwbgr0cnmx I lavori che si trovano nei voli sono in esecuzione, ma la segnalazione di stato a GitHub Pull Requests potrebbe fallire.

2. 17 agosto 2026 alle ore 14:25 UTCidentified

   Stiamo continuando a vedere alti tassi di errore sulle API GitHub e traffico webhook ridotto. Continueremo a fornire aggiornamenti come ulteriori informazioni diventano disponibili.

3. 17 agosto 2026 alle ore 15:49 UTCidentified

   Stiamo continuando a vedere alti tassi di errore sulle API di GitHub e ridotto traffico webhook. I clienti che utilizzano GitHub come loro VCS possono avere un impatto sulla loro esperienza di piattaforma CircleCI di conseguenza. Questo è direttamente collegato all'incidente che GitHub sta vivendo: https://www.githubstatus.com/incidents/zkxwbgr0cnmx Forniremo aggiornamenti come ulteriori informazioni diventano disponibili.

4. 17 agosto 2026 alle ore 16:22 UTCmonitoring

   Abbiamo iniziato a osservare una migliore stabilità nelle API GitHub. Continueremo a monitorare mentre guariscono.

5. 17 agosto 2026 alle ore 17:01 UTCmonitoring

   GitHub API tassi di errore e latencies sembrano essere recuperati. Continueremo a monitorare.

6. 17 agosto 2026 alle ore 17:23 UTCmonitoring

   Alcune delle API di GitHub sono ancora degradate, con conseguente un piccolo numero di guasti relativi agli aggiornamenti di stato di commit e all'elaborazione del gancio. Continueremo a fare del nostro meglio per mitigare questi effetti.

7. 17 agosto 2026 alle ore 19:05 UTCresolved

   Le API di GitHub sembrano funzionare normalmente.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 15 agosto 2026 alle ore 13:58 UTCresolved

   Dopo la manutenzione prevista che si è conclusa alle 13:00 UTC il 15 agosto, alcuni impatti per l'elaborazione del lavoro sono proseguiti per circa 30 minuti oltre la finestra che abbiamo annunciato. Alcuni clienti hanno continuato a vedere ritardi nei posti di lavoro a partire, insieme a un piccolo numero di posti di lavoro che non hanno avuto errori di infrastruttura, fino a circa 13:30 UTC. Questo è stato risolto e il processo di lavoro è tornato alla normalità. I clienti i cui lavori sono falliti durante questa finestra possono eseguire lavori colpiti. Vi ringraziamo per la vostra pazienza mentre il nostro team ha lavorato per l'attuazione di una correzione e scusarsi per qualsiasi inconveniente che l'impatto prolungato potrebbe aver causato.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 12 agosto 2026 alle ore 16:33 UTCidentified

   GitHub is currently experiencing a service degradation (https://www.githubstatus.com/incidents/76t89hbfb09h). Customers who use GitHub as their VCS may experience impact to their CircleCI platform experience as a result, impacting checkout and workflows. We will provide another update as we have more information to share. Thank you for your patience.

2. 12 agosto 2026 alle ore 16:43 UTCresolved

   The issue impacting customers who use GitHub as their VCS while GitHub was undergoing a service degradation (https://www.githubstatus.com/incidents/76t89hbfb09h) has now been resolved. GitHub has resolved the underlying issue and the affected functionality has returned to normal. We thank you for your patience.

1. 11 agosto 2026 alle ore 17:42 UTCresolved

   Between 13:50 UTC and approximately 17:30 UTC on August 11, 2026, some customers experienced delays of up to an hour in pipeline status updates and in notification delivery. Between 16:40 UTC and 17:00 UTC within that same window, a small number of customers also saw newly created pipelines fail to process, appearing in an errored state in the UI and API. The issue has been resolved and all affected functionality has returned to normal. Customers whose pipelines errored during that window can retrigger them. We thank you for your patience while our team worked on implementing a fix.

1. 6 agosto 2026 alle ore 13:06 UTCinvestigating

   Usage API data is delayed for 8/5/2026. All prior data remains available. We are investigating. Thank you for your patience.

2. 6 agosto 2026 alle ore 15:06 UTCidentified

   The issue has been identified and a fix is in progress.

3. 6 agosto 2026 alle ore 19:33 UTCmonitoring

   A fix is in place and is being monitored. Thanks for your patience.

4. 6 agosto 2026 alle ore 19:54 UTCresolved

   The Usage API issue has been resolved. Data has been loaded for yesterday, 8/5/2026. We appreciate your patience.

1. 5 agosto 2026 alle ore 16:58 UTCinvestigating

   We are seeing an issue with Insights service where the data from the last 24 hours is lagging. We are investigating.

2. 5 agosto 2026 alle ore 17:46 UTCinvestigating

   We are continuing to investigate and will update as we know more.

3. 5 agosto 2026 alle ore 18:25 UTCidentified

   We have identified the issue, and are working with our upstream provider to resolve it now.

4. 5 agosto 2026 alle ore 21:01 UTCresolved

   The upstream issue has been resolved, and the insights data from the last 24 hours has caught up. Thank you for your patience.

1. 4 agosto 2026 alle ore 19:27 UTCinvestigating

   We are experiencing increased queue times for Windows, Android, and GPU jobs due to capacity constraints with a third-party infrastructure provider. Jobs will continue to be processed but may take longer than usual to start. Thank you for your patience while our engineers work to resolve this.

2. 4 agosto 2026 alle ore 19:59 UTCmonitoring

   We're starting to see queue times slowly recovering. We'll be monitoring this situation, we appreciate your patience.

3. 4 agosto 2026 alle ore 20:33 UTCmonitoring

   Queue times continue to gradually recover with our third-party infrastructure provider, though we've seen a slight uptick in the last 30 mins. We're keeping an eye on this and will keep you updated as things get back to normal. Again, thank you for your patience.

4. 4 agosto 2026 alle ore 21:16 UTCmonitoring

   Queue times for both Android and Windows jobs, which had been recovering, have started to rise again. This continues to be related to capacity constraints with our third-party infrastructure provider. We'll continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.

5. 4 agosto 2026 alle ore 21:46 UTCmonitoring

   Queue times for both Android and Windows jobs continue to be volatile, with sharp swings up and down. This remains related to capacity constraints with our third-party infrastructure provider. Our team will continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.

6. 4 agosto 2026 alle ore 22:20 UTCmonitoring

   Queue times for both Android and Windows jobs, affected by capacity constraints with our third-party infrastructure provider, have been recovering significantly for the last half hour. We're continuing to monitor for a bit longer to confirm they return to normal levels. We appreciate your patience.

7. 4 agosto 2026 alle ore 23:40 UTCresolved

   Queue times for Android and Windows jobs have reduced significantly over the last hour. You may still notice brief, isolated queuing at times, but this is no longer at incident-level impact. This was related to capacity constraints with a third-party infrastructure provider. We thank you for your patience while we monitored the situation. If you have any issues, please reach out to our Support team.

1. 24 luglio 2026 alle ore 16:35 UTCidentified

   GitHub sta attualmente sperimentando un degrado dei servizi (https://www.githubstatus.com/incidents/yjysg0xrl67m). I clienti che utilizzano GitHub come loro VCS possono avere un impatto sulla loro esperienza di piattaforma CircleCI, influenzando il checkout e i flussi di lavoro. Forniamo un altro aggiornamento in quanto abbiamo più informazioni da condividere. Grazie per la pazienza.

2. 24 luglio 2026 alle ore 17:41 UTCresolved

   Il problema riguarda i clienti che utilizzano GitHub come VCS mentre GitHub stava subendo un degrado di servizio (https://www.githubstatus.com/incidents/yjysg0xrl67m) è stato risolto. GitHub ha risolto il problema sottostante e la funzionalità interessata è tornata alla normalità. Vi ringraziamo per la vostra pazienza.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 22 luglio 2026 alle ore 19:57 UTCinvestigating

   Stiamo indagando i ritardi nell'avvio dei lavori utilizzando la classe delle risorse gen3.

2. 22 luglio 2026 alle ore 23:17 UTCinvestigating

   Stiamo continuando a indagare tempi di attesa elevati che interessano i clienti che utilizzano esecutori di macchine gen3. I lavori interessati possono richiedere più tempo del solito per iniziare. Forneremo un altro aggiornamento non appena avremo più informazioni da condividere.

3. 23 luglio 2026 alle ore 00:31 UTCinvestigating

   Abbiamo identificato il problema e stiamo lavorando con il nostro fornitore per risolvere la disponibilità di risorse gen 3. Gen 1 e Gen 2 sono entrambi completamente operativi.

4. 23 luglio 2026 alle ore 02:05 UTCresolved

   Tra le 19:24 UTC il 22 luglio e le 01:50 UTC il 23 luglio, i clienti che utilizzano le classi di risorse della macchina di anteprima gen3 (Linux VM) hanno sperimentato ritardi e, in alcuni casi, i lavori che non hanno inizio. Abbiamo rimosso le classi di risorse gen3 mentre affrontiamo problemi di stabilità che li riguardano. Purtroppo, i flussi di lavoro che non siamo stati in grado di fornire capacità di calcolo durante questo periodo sono stati annullati. I clienti interessati dovrebbero cambiare la loro classe di risorse da gen3 a gen2 e rifare quei flussi di lavoro. Vi ringraziamo per la vostra pazienza mentre il nostro team ha lavorato per risolvere questo problema.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 22 luglio 2026 alle ore 06:13 UTCmonitoring

   Un sottoinsieme di clienti può avere errori di caricamento app.circleci.com a partire da 03:18 UTC. Una soluzione è stata implementata e stiamo monitorando per il pieno recupero. Grazie per la vostra pazienza mentre i nostri ingegneri confermano il recupero. Forneremo un altro aggiornamento a breve.

2. 22 luglio 2026 alle ore 06:27 UTCresolved

   Tra 03:18 UTC e 06:04 UTC il 22 luglio 2026, un sottoinsieme di clienti erano in grado di accedere app.circleci.com. Il problema è stato risolto e l'accesso è tornato alla normalità. Vi ringraziamo per la vostra pazienza mentre il nostro team ha lavorato per la realizzazione di una soluzione.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 20 luglio 2026 alle ore 00:35 UTCidentified

   Abbiamo identificato un problema con le richieste API GitHub che potrebbero causare alcuni clienti a vedere i flussi di lavoro bloccati in uno stato in esecuzione o flussi di lavoro non riescono a iniziare. GitHub ha segnalato incidenti sulle API https://www.githubstatus.com/incidents/ph5nns5y4gxj https://www.githubstatus.com/incidents/8vfyvq16hzh9 Stiamo monitorando la stabilità delle API GitHub e aggiorneremo questa pagina come ulteriori informazioni sono disponibili.

2. 20 luglio 2026 alle ore 01:24 UTCidentified

   Stiamo anche vedendo errori di elaborazione push event webhooks a causa dell'outage API a monte. Gli utenti potrebbero aver bisogno di riprovare le pipeline per questi eventi push.

3. 20 luglio 2026 alle ore 01:36 UTCmonitoring

   Stiamo vedendo segni di recupero dall'API GitHub. Resteremo in uno stato di monitoraggio per verificare che il tasso di errore API sia stato recuperato.

4. 20 luglio 2026 alle ore 01:45 UTCresolved

   I tassi di errore GitHub API sono stati recuperati ai livelli normali. Durante l'incidente, alcuni clienti potrebbero aver visto tubazioni non avviare o non ricevere aggiornamenti di stato. Alcuni condotti possono essere bloccati in uno stato di esecuzione. * È necessario ri-push commit o utilizzare l'interfaccia utente per attivare manualmente tubazioni che non hanno iniziato. * Le tubature in uno stato in esecuzione bloccato devono essere annullate e riscattate. Se si incontrano problemi si prega di contattare il supporto CircleCI.

5. 23 luglio 2026 alle ore 21:10 UTCpostmortem

   # Il 20 luglio 2026 dalle 00:22 alle 01:45 UTC, i clienti CircleCI che utilizzano le nostre integrazioni GitHub hanno sperimentato guasti in esecuzione di tubazioni e flussi di lavoro esperti che si bloccano. Durante questo incidente, alcuni condotti innescati dagli utenti che utilizzano GitHub non sono riusciti a avviare o eseguire come pipeline di errore. I clienti i cui oleodotti hanno fallito o eseguito come pipeline di errore durante questa finestra dovrebbero ri-correrli. Ciò è stato causato da un [digrado delle API a monte su GitHub](https://www.githubstatus.com/incidents/ph5nns5y4gxj), che ha colpito molte API GitHub che CircleCI utilizza per attivare ed eseguire tubazioni. Entro le 01:45 UTC, GitHub API recuperate, e il cliente pipelines corse normalmente. La pagina iniziale di stato CircleCI si trova [qui](https://status.circleci.com/incidents/9lvbbbs9l87b). # What Happened # \(tutte le volte UTC\) Inizio 00:22 il 20 luglio 2026, GitHub ha iniziato a restituire errori elevati per le seguenti richieste API: * `applicazioni/*/token` * `repos/*/commits` * `repos/*/*/contents/*` * `repos/*/*/hooks` * `repos/*/*/hooks/*` * `repos/*/*/keys` * `repos/*/*/puls` * `repos/*/*/statuses/*` CircleCI si basa su queste richieste per attivare correttamente e eseguire tubazioni. Alle 00:22, il nostro monitoraggio interno ci ha avvertito al problema. Il nostro team ha iniziato a indagare, e ha scoperto che un piccolo numero di condotte appartenenti a progetti GitHub non è riuscito a iniziare o eseguire come condotte di errore. Ciò includeva tubazioni e flussi di lavoro programmati. Inoltre, un piccolo numero di flussi di lavoro del cliente ha sperimentato lavori bloccati e ha richiesto una ri-run del flusso di lavoro per risolvere. A 01:45, GitHub recuperato e trattamento pipeline restituito a livelli operativi normali. Solo le tubazioni innescate durante la finestra incidente sono state colpite, e i clienti dovrebbero eseguire nuovamente tali tubazioni. ## Prevenzione futura e miglioramento dei processi Stiamo lavorando attivamente per migliorare la resilienza dell'elaborazione delle tubazioni durante le interruzioni del servizio GitHub per ridurre l'impatto del cliente di incidenti simili in futuro. Stiamo individuando funzioni che aiuteranno i clienti a recuperare con passaggi manuali ridotti dopo la risoluzione degli incidenti. L'esperienza del cliente è la nostra priorità, e ci impegniamo a migliorare continuamente l'affidabilità dei nostri sistemi per soddisfare la fiducia che i nostri clienti ci pongono. Si prega di raggiungere il nostro team di supporto con qualsiasi domanda o preoccupazione.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 16 luglio 2026 alle ore 23:04 UTCinvestigating

   Stiamo indagando su un problema in cui i clienti possono vedere gli errori di caricamento dell'app Web CircleCI e la firma, insieme a tubazioni e flussi di lavoro programmati che non riescono ad avviare o eseguire in ritardo. Ciò è legato a un incidente in corso che interessa GitHub. È possibile seguire lo stato di GitHub al https://www.githubstatus.com/incidents/gxycch3076xk. I nostri ingegneri stanno indagando attivamente. Forneremo un altro aggiornamento non appena avremo più informazioni da condividere.

2. 16 luglio 2026 alle ore 23:42 UTCidentified

   Stiamo continuando a vedere alti tassi di fallimento da GitHub APIs che stanno influenzando l'elaborazione di login e flusso di lavoro. Continueremo a monitorare l'API GitHub per il recupero.

3. 17 luglio 2026 alle ore 00:09 UTCmonitoring

   Cosa sta succedendo? L'incidente a monte di GitHub è stato mitigato e ora viene monitorato da GitHub. È possibile seguire lo stato di GitHub all'indirizzo https://www.githubstatus.com/. Cosa puoi aspettarti L'accesso all'app web CircleCI, al sign-in, al processo di pipeline e flusso di lavoro stanno tornando alla normalità. Si possono ancora vedere errori intermittenti o ritardati tubazioni e flussi di lavoro programmati come sistemi stabilizzanti. Grazie per la vostra pazienza mentre monitoriamo per il pieno recupero.

4. 17 luglio 2026 alle ore 00:26 UTCresolved

   Un incidente che riguarda l'API di GitHub ha causato ai clienti CircleCI l'esperienza di errori di caricamento dell'app web e di accesso, insieme a pipeline e flussi di lavoro programmati che non riescono a avviare o eseguire in ritardo. GitHub ha risolto l'incidente sottostante (https://www.githubstatus.com/) e tutte le funzionalità colpite sono tornate alla normalità. I clienti i cui lavori o tubazioni non sono riusciti possono riscattarli. Le tubazioni programmate e i flussi di lavoro che sono stati persi durante l'incidente non verranno eseguiti automaticamente e dovranno essere riattivati. Vi ringraziamo per la vostra pazienza.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 14 luglio 2026 alle ore 22:54 UTCidentified

   Il 13 luglio tra le 15:30 UTC e le 22:40 UTC, abbiamo sperimentato ritardi di avvio di lavori su Docker (Gen 2) classi di risorse a causa di vincoli di capacità dal nostro provider cloud. Delays ha raggiunto fino a circa 1 minuto 48 secondi. Stiamo continuando a sperimentare nuovamente questi ritardi da circa 15:45 UTC. Finora, i ritardi hanno raggiunto fino a circa 1 minuto 19 secondi. Stiamo lavorando con il nostro provider cloud per aggiungere capacità e aggiorneremo questo incidente come la situazione cambia.

2. 15 luglio 2026 alle ore 00:32 UTCresolved

   Il 13 luglio tra le 15:30 UTC e le 22:40 UTC, abbiamo sperimentato ritardi di avvio di lavori su Docker (Gen 2) classi di risorse a causa di vincoli di capacità dal nostro provider cloud. Lo stesso numero si è ripreso il 14 luglio tra 15:45 UTC e 22:50 UTC. I ritardi hanno raggiunto fino a 25 minuti il 13 luglio e fino a 24 minuti il 14 luglio. Le classi di risorse medio+ e 2 X-large+ hanno visto le attese più lunghe. Gli aggiornamenti precedenti di questo incidente hanno riferito le cifre basate sui tempi di attesa medi, che non riflettevano l'impatto massimo che alcuni clienti potrebbero avere sperimentato. I tempi di attesa sono tornati alla normalità. Stiamo continuando a lavorare con il nostro provider cloud per aggiungere capacità prima del prossimo periodo di punta. Grazie per la pazienza.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 14 luglio 2026 alle ore 02:49 UTCinvestigating

   Stiamo attualmente indagando errori di login che interessano alcuni clienti che utilizzano Bitbucket come loro fornitore di identità.

2. 14 luglio 2026 alle ore 03:29 UTCinvestigating

   Il nostro team continua a indagare sugli errori di login che interessano alcuni clienti che utilizzano Bitbucket come fornitore di identità.

3. 14 luglio 2026 alle ore 03:51 UTCinvestigating

   Cosa c'è di impatto Alcuni clienti che si collegano con un'identità Bitbucket-linked sono colpiti. Questo può anche includere i clienti che si collegano con GitHub, ma hanno un'identità Bitbucket collegata sul loro conto. Inoltre, alcuni clienti stanno sperimentando flussi di lavoro che non stanno iniziando o aggiornando. Cosa puoi aspettarti I clienti interessati possono vedere errori di login. Alcuni clienti possono anche notare flussi di lavoro che non iniziano o non aggiornano come previsto. Grazie per la vostra pazienza mentre i nostri ingegneri indagano. Prossimo aggiornamento Forniremo un altro aggiornamento non appena avremo maggiori informazioni da condividere

4. 14 luglio 2026 alle ore 04:21 UTCmonitoring

   Cosa c'è di impatto Alcuni clienti che si collegano con un'identità Bitbucket-linked sono stati colpiti. Ciò potrebbe anche aver incluso i clienti che si collegano con GitHub che hanno un'identità Bitbucket collegata sul loro conto. Alcuni clienti hanno anche sperimentato flussi di lavoro che non hanno iniziato o aggiornato. Cosa puoi aspettarti Una soluzione è stata implementata. Stiamo monitorando la situazione per confermare il pieno recupero. Prossimo aggiornamento Forniremo un aggiornamento se qualcosa cambia

5. 14 luglio 2026 alle ore 05:15 UTCresolved

   Il problema in cui i clienti si registrano con un'identità collegata a Bitbucket ha sperimentato errori di login, e alcuni clienti hanno sperimentato flussi di lavoro che non hanno iniziato o non hanno aggiornato, è stato risolto. Ciò che si può ancora sperimentare e la necessità di fare - Se si utilizza Bitbucket come metodo di login, si prega di uscire e ripristinare l'integrazione CircleCI Bitbucket sul proprio account. - Se uno dei vostri flussi di lavoro è bloccato o mostra i controlli di stato mancanti, si prega di eseguire loro per prendere la correzione. - Se si continua a sperimentare problemi dopo aver preso questi passaggi, si prega di raggiungere il supporto CircleCI. Vi ringraziamo per la vostra pazienza mentre il nostro team ha lavorato per la realizzazione di una soluzione.

6. 14 luglio 2026 alle ore 22:31 UTCpostmortem

   # Dal 01:33 UTC al 05:18 UTC il 14 luglio 2026, i clienti con un'identità Bitbucket-linked non sono stati in grado di accedere a CircleCI, e alcuni clienti hanno sperimentato flussi di lavoro che non è riuscito a iniziare o aggiornare, a causa di un cambiamento nel modo in cui il servizio di Bitbucket riferisce autorizzazioni account. Alle 05:07 UTC, abbiamo implementato una correzione che ha corretto come i nostri sistemi leggono il campo autorizzazioni aggiornato. Alcuni clienti dovevano uscire e ri-autenticicare la loro integrazione Bitbucket dopo che abbiamo implementato la correzione. I nostri sistemi hanno continuato a elaborare il backlog dei lavori colpiti fino alle 08:39 UTC. Ringraziamo i nostri clienti per la loro pazienza come abbiamo risolto questo incidente. Si prega di raggiungere il nostro team di supporto con qualsiasi domanda o preoccupazione. La pagina di stato per questo incidente si trova [qui](https://status.circleci.com/incidents/gsyjwybg477g). ## Sfondo CircleCI supporta l'accesso con un account GitHub, un account Bitbucket, o una email e una password. Quando un cliente accede con un'identità collegata a Bitbucket, o quando CircleCI ha bisogno di aggiornare l'accesso del cliente per loro conto, scambiamo un token di autorizzazione con il servizio OAuth di Bitbucket. Questo scambio include un elenco delle autorizzazioni, o "scopi", il cliente ci ha concesso, che Bitbucket e CircleCI usano per confermare ciò che CircleCI è autorizzato a fare per conto del cliente. # What Happened # \(Tutte le volte UTC\) L'8 aprile 2026 [Bitbucket ha annunciato una modifica al suo servizio OAuth](https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3139): si tratterebbe di rinominare il campo utilizzato per segnalare le autorizzazioni concesse dal cliente. Bitbucket ha eseguito un periodo di transizione durante il quale sono stati disponibili sia i nomi vecchi che nuovi campi, quindi completamente rimosso il vecchio nome campo il 4 maggio 2026. I nostri sistemi non erano stati aggiornati per riconoscere il nuovo nome di campo, quindi una volta Bitbucket completamente eliminato il vecchio, le richieste che dipendevano da esso hanno cominciato a fallire. Alle 01:33 del 14 luglio 2026, i nostri sistemi cominciarono a non elaborare le informazioni dei permessi restituiti per i conti collegati a Bitbucket, perché i nostri sistemi si aspettavano ancora la vecchia struttura dei permessi. Questo ha causato tentativi di login per tutti gli account Bitbucket-linked a fallire, compresi i clienti che si collegano con GitHub ma hanno un'identità Bitbucket collegata al loro account. Alle 01:59, il monitoraggio automatizzato ha avvertito il nostro team di ingegneria a un picco di errori sui sistemi colpiti. Il team ha iniziato a indagare immediatamente, ha confermato l'impatto del cliente alle 02:38, e ha avvisato i clienti attraverso la nostra pagina di stato alle 02:51. Entro le 03:00, la squadra aveva isolato i guasti al rinominato campo Bitbucket. A partire dal 03:17, gli aggiornamenti di stato del flusso di lavoro per le tubazioni di Bitbucket appartenenti ai clienti con un token di accesso scaduto hanno cominciato a essere caduti. Il controllo delle autorizzazioni Bitbucket viene utilizzato ampiamente attraverso la nostra piattaforma, e questi fallimenti di autorizzazioni hanno anche interessato alcuni dei nostri sistemi di elaborazione del lavoro interni. Ciò ha causato un sottoinsieme di flussi di lavoro a rimanere bloccato senza uno stato finale, e ha causato alcune richieste di tirare per mostrare assegni mancanti o bloccati. Alle 04:21, il team ha implementato una correzione iniziale che ha risolto il problema sottostante, ripristinando il flusso di login e riportando il nostro sistema di autorizzazioni interne al normale funzionamento. Alcuni clienti interessati hanno bisogno di uscire e accedere per prendere la correzione. Entro le 05:07, il team ha implementato due correzioni aggiuntive in modo che i nostri sistemi inizierebbero ad accettare il nuovo formato di campo di autorizzazioni di Bitbucket andare avanti. Abbiamo risolto l'incidente alle 05:18. Alcuni clienti hanno avuto bisogno di uscire e ri-autenticicare la loro integrazione Bitbucket prima che il loro account completamente recuperato. I nostri sistemi hanno continuato a elaborare un backlog di posti di lavoro colpiti, tornando a livelli normali di circa 08:39. ## Prevenzione futura e miglioramento dei processi Stiamo facendo i seguenti passi per prevenire una ricorrenza e migliorare il nostro tempo di risposta: **Stiamo indurendo il nostro codice di autorizzazione contro le modifiche delle API a monte.** Questo incidente è accaduto perché il nostro sistema non ha gestito con grazia un campo rinominato in una risposta da un fornitore di identità di terze parti. Stiamo aggiornando immediatamente il nostro codice di autorizzazione in modo che i campi inaspettati o mancanti da GitHub, Bitbucket e GitLab siano gestiti in modo sicuro. **Stiamo migliorando come monitoriamo i cambiamenti del fornitore a monte.** Attualmente monitoriamo già i changelog dai nostri fornitori di identità per esattamente questo tipo di cambiamento di rottura, ma non abbiamo aggiunto questo particolare cambiamento di fornitore al nostro monitoraggio in tempo per catturarlo prima di spedirlo. Stiamo verificando e espandendo questo monitoraggio in modo che gli annunci dei fornitori raggiungano il nostro team prima che colpiscano i clienti. **Stiamo migliorando come classifichiamo e comunichiamo gli incidenti nei loro primi minuti.** La classificazione iniziale di questo incidente non rifletteva immediatamente la sua gravità rispetto al cliente. Stiamo rifinanziando il nostro strumento di incidente e guida per aiutare gli ingegneri a identificare e comunicare l'impatto del cliente più rapidamente. **Stiamo migliorando la resilienza del nostro flusso di lavoro.** Un guasto a valle in questo incidente ha causato alcuni aggiornamenti di stato del flusso di lavoro da eliminare piuttosto che retried o chiaramente superficie. Stiamo rivedendo il comportamento di riprova e gestione degli errori di questo sistema in modo che i guasti a valle simili siano più visibili e più facili da recuperare. L'esperienza del cliente è la nostra priorità, e ci impegniamo a migliorare continuamente l'affidabilità dei nostri sistemi per soddisfare la fiducia che i nostri clienti ci pongono. Si prega di raggiungere il nostro team di supporto con qualsiasi domanda o preoccupazione.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 luglio 2026 alle ore 21:52 UTCinvestigating

   Abbiamo ricevuto alcune segnalazioni di problemi di rete intermittenti tra la nostra infrastruttura mac e un provider VCS di nuovo. Stiamo indagando e forniremo aggiornamenti.

2. 13 luglio 2026 alle ore 22:21 UTCinvestigating

   Stiamo ancora indagando su questi problemi di rete intermittenti. Ci aggiorneremo di nuovo a breve, apprezziamo la vostra pazienza.

3. 13 luglio 2026 alle ore 23:13 UTCinvestigating

   Siamo riusciti a riprodurre il problema, ma sembra ancora molto intermittente. Stiamo continuando a lavorare con il nostro provider di infrastrutture Mac per aiutare a diagnosticare il problema. Ci aggiorneremo presto.

4. 13 luglio 2026 alle ore 23:35 UTCmonitoring

   Abbiamo identificato il problema. Alcuni clienti possono sperimentare posti di lavoro che appendere o non riescono a progredire durante i passi Github fetch a causa di problemi di rete intermittenti. I nostri ingegneri stanno monitorando attivamente. Nel frattempo, abbiamo visto il successo aumentando il no output timeout a 15 - 20 min per consentire più tempo per Github fetches. Questo può essere fatto seguendo questa guida comunitaria: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

5. 14 luglio 2026 alle ore 13:59 UTCidentified

   Purtroppo ci sono ancora alcuni clienti che possono essere sperimentando posti di lavoro che si bloccano o non riescono a progredire durante i passi Github fetch a causa di problemi di rete intermittenti in corso con il nostro provider di infrastrutture Mac. I nostri ingegneri stanno lavorando attivamente con loro per risolvere questo problema. Apprezziamo la vostra pazienza. Nel frattempo, abbiamo visto il successo aumentando il no output timeout a 15 - 20 min per consentire più tempo per Github fetches. Questo può essere fatto seguendo questa guida comunitaria: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

6. 14 luglio 2026 alle ore 15:35 UTCidentified

   Il nostro provider di infrastrutture Mac sta testando le modifiche alla loro configurazione di rete nel tentativo di isolare la fonte del problema. Stiamo attivamente convalidando se questo risolve l'impatto e seguirà un altro aggiornamento presto. Nel frattempo, aumentare il no output timeout a 15-20 min continua ad aiutare: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

7. 14 luglio 2026 alle ore 16:31 UTCidentified

   Abbiamo identificato il problema come alcuni percorsi in entrata dal fornitore VCS interessato causando significativamente inferiore larghezza di banda disponibile che è negativamente impatto tempi di recupero. Stiamo lavorando con il nostro provider di infrastrutture Mac per tentare di spostare il traffico in entrata in un percorso diverso, tuttavia questo processo potrebbe richiedere un lungo periodo di tempo per completare. Continueremo a fornire aggiornamenti come diventano disponibili. Come abbiamo condiviso negli aggiornamenti precedenti, aumentando il no output timeout a 15-20 min continua ad aiutare: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

8. 14 luglio 2026 alle ore 16:58 UTCmonitoring

   Il nostro fornitore di infrastrutture Mac ha spostato le rotte in entrata e stiamo vedendo il recupero nei tempi di fetch VCS. Continueremo a monitorare questo problema nelle prossime ore. Ci aggiorneremo presto.

9. 14 luglio 2026 alle ore 18:28 UTCmonitoring

   Stiamo continuando a vedere il lento e progressivo recupero nei tempi di cattura del VCS. Continueremo a monitorare e aggiornare di nuovo presto. Apprezziamo la vostra pazienza.

10. 14 luglio 2026 alle ore 20:18 UTCinvestigating

    Stiamo iniziando a vedere i tempi di recupero del VCS. Il nostro team di ingegneria sta attivamente indagando e lavorando con il nostro fornitore di infrastrutture Mac per risolvere questo problema. Ancora una volta, apprezziamo la vostra pazienza.

11. 14 luglio 2026 alle ore 22:15 UTCmonitoring

    Il nostro fornitore di infrastrutture Mac ha spostato più traffico verso i fornitori di rete di lavoro e stiamo iniziando a vedere il recupero significativo di nuovo in tempi di fetch VCS. Come sempre, il nostro team di ingegneri continuerà a monitorare da vicino questo e forniremo un altro aggiornamento presto.

12. 14 luglio 2026 alle ore 23:18 UTCresolved

    Continuiamo a vedere un significativo recupero di tempo di recupero di VCS fetch durante le ultime due ore. Risolveremo l'incidente e il nostro team di ingegneri continuerà a monitorare da vicino. Apprezziamo molto la vostra pazienza come abbiamo lavorato attraverso questo con il nostro fornitore di infrastrutture Mac. Si prega di raggiungere il nostro team di supporto se avete problemi.

13. 16 luglio 2026 alle ore 01:56 UTCpostmortem

    # A partire dalle 18:00 UTC il 13 luglio 2026 a 23:18 UTC il 14 luglio 2026, alcuni clienti che gestiscono lavori sulla flotta macOS di CircleCI hanno sperimentato lavori che hanno appeso o non sono riusciti a progredire durante i passi GitHub fetch. Per questi clienti, GitHub fetch passi che normalmente prendere 1-2 minuti ha preso 20-30 minuti, e timed fuori. Il problema è stato causato da un problema di capacità e routing sul percorso di rete tra il nostro provider di infrastrutture Mac e GitHub, e i problemi di rete intermittenti associati rallentato fetches da GitHub. Durante l'intero incidente, il nostro team ha lavorato direttamente con il nostro provider di infrastrutture Mac per identificare e reindirizzare il traffico lontano dai percorsi di rete interessati. Abbiamo risolto un evento iniziale alle 19:40 UTC il 13 luglio. Il problema ha ripreso a 21:52 UTC quel giorno, abbiamo riaperto l'incidente, ed è stato completamente risolto da 23:18 UTC il 14 luglio. La nostra flotta di macOS ha avuto un problema simile diverse settimane fa. Dal 20:18 UTC il 24 giugno 2026 al 03:09 UTC il 25 giugno 2026, i clienti hanno sperimentato un [simile incidente](https://status.circleci.com/incidents/gvysjmkf4ct9) che interessa la capacità di macOS posti di lavoro per raggiungere GitHub. Tale incidente è stato causato anche da un problema di routing di rete nel nostro provider di infrastrutture Mac. Ringraziamo i nostri clienti per la loro pazienza mentre abbiamo lavorato attraverso questo incidente. Si prega di vedere di seguito per azioni specifiche che CircleCI e il nostro fornitore di infrastrutture Mac stanno prendendo. Si prega di raggiungere il nostro team di supporto con qualsiasi domanda o preoccupazione. Le pagine di stato di questo incidente possono essere trovate [qui](https://status.circleci.com/incidents/n1tc2lw9q7l0) e [qui](https://status.circleci.com/incidents/7cnl777wp9qz). ## Sfondo I lavori di macOS di CircleCI sono ospitati su un fornitore di infrastrutture Mac di terze parti. Questo provider si connette a Internet più ampio, compresi i servizi come GitHub, su più percorsi di rete a monte ridondanti. Quando uno di questi percorsi sta sperimentando una capacità ridotta o un problema di routing, i lavori che stanno recuperando codice o dipendenze da una destinazione lungo quel percorso di rete possono rallentare o appendere intermittentemente, anche quando la piattaforma di CircleCI, il fornitore di infrastrutture di terze parti, e il servizio di destinazione sono tutti operativi normalmente. # What Happened # \(Tutte le volte UTC\) Alle 18:00 del 13 luglio, alcuni clienti che eseguono lavori macOS hanno iniziato a sperimentare guasti intermittenti e ritardi di acquisizione codice e dipendenze da GitHub. Abbiamo aperto un'indagine e avvisato i nostri clienti attraverso la nostra pagina di stato alle 18:55. Entro le 19:04, il nostro provider di infrastrutture Mac ha identificato un aumento della latenza su uno dei suoi percorsi di rete e traffico reindirizzato intorno a esso. Tempo di recupero, e abbiamo spostato l'incidente a `Monitoring` a 19:29, e a `Risolto` a 19:40. Alle 20:44 UTC, i clienti hanno riferito che il problema era tornato. Abbiamo riaperto l'incidente e aggiornato la nostra pagina di stato a `Investigating` alle 21:52. Nelle due ore successive, abbiamo lavorato a stretto contatto con il nostro fornitore di infrastrutture per raccogliere dati diagnostici nel tentativo di isolare il percorso di rete interessato. Nel frattempo, abbiamo pubblicato la guida raccomandando ai clienti di aumentare la loro impostazione `no output timeout` a 15-20 minuti, per consentire più tempo per GitHub fetches per completare durante i rallentamenti intermittenti, e spostato la pagina di stato a `Monitoring` a 23:35. Dopo aver pubblicato la guida di lavoro a 23:35 UTC il 13 luglio, ci aspettavamo il problema di rete sottostante per migliorare la notte. No. A 13:59 UTC il 14 luglio, abbiamo confermato che i clienti stavano ancora sperimentando guasti intermittenti e spostato la pagina di stato a `Investigating`. Il nostro team di ingegneria ha riprodotto il fallimento utilizzando direttamente i nostri strumenti di prova, che ha contribuito a confermare che questo era un problema generale `git-fetch` piuttosto che qualcosa specifico per qualsiasi particolare strumento di costruzione, immagine del contenitore, o aggiornamento del software. Alle 15:35, abbiamo aggiornato la pagina di stato per condividere che il nostro fornitore di infrastrutture stava testando le modifiche alla sua configurazione di rete per isolare la fonte del problema. Alle 16:31, abbiamo aggiornato nuovamente la pagina di stato per condividere che avevamo identificato la causa come ridotta larghezza di banda in entrata su un percorso specifico, e che stavamo lavorando con il nostro fornitore per spostare il traffico in un percorso diverso. Alle 16:36, il nostro fornitore di infrastrutture ha identificato i percorsi di rete interessati e spostato il traffico lontano da loro, tempi di arresto recuperati, e alle 16:58, abbiamo aggiornato la pagina di stato a `Monitoring`. Nel primo pomeriggio, alcuni clienti stavano nuovamente vedendo tempi di fetch lenti, e abbiamo spostato la pagina di stato a `Investigating` a 20:18. Il nostro fornitore di infrastrutture ha identificato due ulteriori percorsi di rete con prestazioni degradate e il traffico spostato via da loro entro le 22:07. Tempi ridotti stabilizzati nell'ora seguente, e abbiamo segnato l'incidente `Risolto` a 23:18. In totale, i clienti che eseguono lavori Mac possono aver sperimentato rallentamenti di lavoro intermittenti o guasti per porzioni della finestra tra le 18:00 UTC il 13 e 23:18 UTC il 14 luglio. Il nostro fornitore di infrastrutture ha da allora segnalato risultati di test puliti in tutta la sua rete e ritiene che il problema di capacità sottostante abbia avuto origine più a monte, più vicino a GitHub, piuttosto che all'interno della propria rete. Stiamo continuando a monitorarlo da vicino. ## Prevenzione futura e miglioramento dei processi Stiamo facendo i seguenti passi per prevenire una ricorrenza e migliorare il nostro tempo di risposta: **Stiamo costruendo un ulteriore monitoraggio automatizzato per le prestazioni della flotta di macOS GitHub-fetch** Il nostro vasto monitoraggio automatizzato non ha preso questo incidente. Stiamo ora aggiungendo il monitoraggio end-to-end per GitHub fetches in particolare, al fine di rilevare problemi simili proattivamente. **Stiamo lavorando direttamente con il nostro provider di infrastrutture Mac su rilevamento più veloce e proattivo.** Chiediamo al nostro fornitore di costruire un monitoraggio in grado di rilevare automaticamente un percorso di rete degradato, piuttosto che affidarsi a CircleCI per identificare e richiedere un reindirizzamento durante un incidente attivo. **Stiamo trasformando lo strumento diagnostico che abbiamo costruito durante questo incidente in una capacità permanente.** Questo ci permetterà di rilevare e riprodurre questa classe di fallimento della rete su richiesta in corso, piuttosto che assemblare l'infrastruttura di prova durante un incidente attivo. ** Stiamo rivedendo il nostro processo di risposta incidente per una finestra di conferma sufficiente prima di marcare un incidente di rete Risolto** Questo incidente si è ripreso brevemente dopo una risoluzione precoce; stiamo formalizzando un periodo minimo di monitoraggio confermato-pulito prima di chiudere gli incidenti di questo tipo. Continueremo a fornire aggiornamenti regolari lungo il percorso di indagine e di bonifica continua. **Ci stiamo muovendo attivamente da un singolo fornitore per l'infrastruttura Mac****a più fornitori.** Ciò consentirà a CircleCI di indirizzare i carichi di lavoro dei clienti in arrivo al fornitore più disponibile e più performante. L'esperienza del cliente è la nostra priorità, e ci impegniamo a migliorare continuamente l'affidabilità dei nostri sistemi per soddisfare la fiducia che i nostri clienti ci pongono. Si prega di raggiungere il nostro team di supporto con qualsiasi domanda o preoccupazione.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 luglio 2026 alle ore 18:55 UTCinvestigating

   Abbiamo ricevuto rapporti di problemi di rete intermittenti tra la nostra infrastruttura mac e un fornitore VCS. Stiamo indagando e forniremo aggiornamenti.

2. 13 luglio 2026 alle ore 19:11 UTCidentified

   Stiamo lavorando con il nostro provider di infrastrutture Mac per tentare una mitigazione. Si aggiornerà di nuovo a breve.

3. 13 luglio 2026 alle ore 19:29 UTCmonitoring

   Il nostro provider di infrastrutture Mac ha implementato una correzione, stiamo iniziando a vedere il recupero. Stiamo monitorando e aggiorneremo di nuovo a breve.

4. 13 luglio 2026 alle ore 19:40 UTCresolved

   Abbiamo confermato la correzione con il nostro fornitore di infrastrutture e test di successo alla nostra fine. Se i clienti continuano a vedere eventuali fallimenti, si prega di eseguire di nuovo per una connessione di successo e raggiungere il supporto se eventuali ulteriori problemi.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.