Integrazioni Bitbucket Cloud scollegate dopo un errore di servizio Bitbucket
Inizio 27 ottobre 2026 alle ore 10:06 UTC · 2h 45m
IssuesIncidente minore
investigating
# Sommario #
Alcune integrazioni Bitbucket Cloud che utilizzano OAuth scollegato dopo che il servizio di autenticazione di Bitbucket ha restituito gli errori il 27 ottobre 2026, alle 03:45 UTC.
# Impatto #
Per le integrazioni interessate, Cycode non può accedere a Bitbucket. Scansioni, sincronizzazioni dei repository e stati di commit per quegli spazi di lavoro si fermano fino a quando l'integrazione è autorizzata di nuovo. Le integrazioni che utilizzano password app, gettoni API o token di accesso allo spazio di lavoro non sono influenzate.
L'ultimo aggiornamento...
La nostra indagine mostra che Bitbucket ha rilasciato nuove credenziali per queste integrazioni, ma non le ha consegnate a Cycode, perché il suo servizio ha restituito un errore. Bitbucket non accetta più le credenziali precedenti, quindi le integrazioni non possono recuperare automaticamente. Stiamo segnalando il problema all'Atlante.
* Azione richiesta *
Se l'integrazione di Bitbucket mostra come disconnesso, autorizzarlo di nuovo nella console Cycode sotto [Impostazioni > Integrazioni > Bitbucket]. Cycode continua da dove si è fermato, e nessun altro cambiamento è necessario.
pubblicheremo un aggiornamento quando avremo maggiori informazioni.
monitoring
Abbiamo identificato ogni integrazione interessata e ora stiamo contattando direttamente i loro utenti. Un'integrazione ricomincia a funzionare non appena il suo utente lo autorizza nuovamente nella console Cycode sotto [Impostazioni > Integrazioni > Bitbucket]. Abbiamo segnalato l'errore Bitbucket a Atlassian e pubblicheremo un aggiornamento quando abbiamo maggiori informazioni.
resolved
Tutte le integrazioni Bitbucket Cloud interessate sono state identificate e i loro utenti hanno ricevuto istruzioni per autorizzarle di nuovo. Integrazioni che sono state autorizzate di nuovo funzionano normalmente.
La causa principale era un errore di servizio Bitbucket il 27 ottobre 2026, alle 03:45 UTC, che invalidò le credenziali di alcune integrazioni. Abbiamo condiviso i dettagli con Atlassian per la loro indagine.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Problemi di flusso di login
Inizio 20 ottobre 2026 alle ore 09:27 UTC · 6h 17m
IssuesIncidente minore
investigating
Abbiamo identificato una potenziale causa dei problemi di flusso di login e stiamo indagando ulteriormente.
investigating
Abbiamo risolto il problema del flusso di login nella regione dell’UE.
monitoring
Il problema è stato risolto, e stiamo continuando a monitorare il sistema per garantire la stabilità.
resolved
L'incidente è stato completamente risolto, e non vediamo ulteriori problemi.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Le questioni relative alla scansione e al caricamento delle infrazioni in Europa
Inizio 18 ottobre 2026 alle ore 13:10 UTC · 1h 31m
IssuesIncidente minore
investigating
Stiamo indagando errori nell'applicazione relativi alla scansione di PR e errori di carico di violazione.
Continueremo a pubblicare ulteriori aggiornamenti una volta trovata la causa.
identified
Abbiamo avuto un problema con uno dei nostri database applicativi.
Il database è tornato alle normali operazioni, ma è ancora degradato, e stiamo attivamente lavorando per risolverlo.
La piattaforma è di nuovo alle normali operazioni, e le violazioni e le scansioni di PR dovrebbero funzionare normalmente.
monitoring
Il database è tornato alle normali operazioni.
Stiamo monitorando attivamente per garantire che non ci siano ancora problemi.
resolved
L'incidente è stato completamente risolto, e non vediamo ulteriori problemi.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Scansioni delle prestazioni degradate
Inizio 13 ottobre 2026 alle ore 09:00 UTC · 0m
IssuesIncidente minore
monitoring
**Monitoring**: scansiona API (regione USA)
Ancora oggi il nostro sistema di avviso ha rilevato che il servizio dietro le scansioni API stava riavviando più spesso del previsto, che ha causato alcune richieste di fallire per un breve periodo. Abbiamo aumentato la memoria disponibile al servizio, ed è stato stabile da allora. Teniamo il servizio sotto stretta osservazione mentre finalizziamo un miglioramento permanente.
resolved
**Risolto**: Breve rallentamento delle scansioni API (regione USA)
Il 13 ottobre 2026, tra 07:58 e 08:28 UTC, alcune richieste
per le scansioni API nella regione degli Stati Uniti fallito o erano lenti. Le pagine di scansione nell'interfaccia utente Cycode e il Cycode CLI potrebbero aver mostrato errori temporanei, e alcune scansioni di richiesta pull sono arrivate pochi minuti dopo il solito.
Abbiamo aumentato la memoria disponibile al servizio, che ha completamente risolto il problema alle 08:34 UTC. Tutte le scansioni in coda completate poco dopo, e nessun dato è stato perso. Abbiamo identificato la causa e un miglioramento permanente è in esame.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
GitLab Service Disruption Affecting Integrazioni Cycode
Inizio 13 ottobre 2026 alle ore 08:30 UTC · 2h 56m
IssuesIncidente minore
investigating
GitLab sta attualmente sperimentando una disgregazione di servizio che può influenzare la scansione di Cycode PR e la connettività di integrazione.
Il problema proviene dall'infrastruttura di GitLab ed è al di fuori del controllo di Cycode. Stiamo monitorando la situazione e fornirà aggiornamenti come GitLab funziona per ripristinare il servizio normale.
Per ulteriori informazioni, fare riferimento alla pagina di stato di GitLab:
[https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3a7005ae52c614](http://status.gitlab.com/pages/incident/5b36dc6502d804c08349f7/6acdd94de3a7005a
monitoring
GitLab ha spostato l'incidente che interessa la scansione di PR e la connettività di integrazione alla fase di monitoraggio.
GitLab ha implementato una correzione e sta monitorando i risultati. Stiamo continuando a monitorare l'impatto sulle integrazioni Cycode e forniremo ulteriori aggiornamenti, se necessario.
Per ulteriori informazioni, fare riferimento alla pagina di stato di GitLab:
[https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3a7005ae52c614](http://status.gitlab.com/pages/incident/5b36dc6502d804c08349f7/6acdd94de3a7005a
resolved
GitLab ha risolto l'incidente che riguarda la scansione delle PR e la connettività di integrazione
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Applicazione e scansione delle prestazioni degradate
Inizio 5 ottobre 2026 alle ore 20:24 UTC · 0m
IssuesIncidente minore
investigating
La squadra continua a lavorare con AWS, che ha aumentato il problema internamente.
Parallelamente, stiamo lavorando per ripristinare la funzionalità spostandosi in un altro database.
Eventuali richieste di pull bloccate in attesa dello stato Cycode possono essere sbloccate rimuovendo le scansioni Cycode dai controlli previsti direttamente nel vostro SCM (Source Code Management). Raggiungi il tuo rappresentante Cycode per aiutarti a semplificare il processo.
investigating
AWS ha confermato che l'istanza PostgreSQL interessata è attualmente in uno stato di recupero interno.
Il failover Multi-AZ atteso non si è verificato come progettato, e AWS sta attivamente indagando perché.
Parallelamente, stiamo continuando a lavorare per ripristinare i servizi interessati utilizzando un percorso di database alternativo per accelerare il recupero
investigating
Stiamo vedendo la banca dati sta ripristinando le sue capacità operative.
Vediamo prima le scansioni di Pull Request in fase di elaborazione.
Stiamo monitorando il sistema e aumentando il throughput.
investigating
Il database rimane pienamente operativo.
Stiamo lavorando ad aumentare la velocità di elaborazione oltre regolarmente per elaborare tutti i backlog il prima possibile.
investigating
Stiamo continuando a indagare su un grande degrado della piattaforma statunitense causata dalla esaurimento della connessione PostgreSQL. I clienti possono sperimentare tempi di risposta lenta, elevati 500 errori, e flussi di lavoro PR più lenti e scansioni CLI.
Abbiamo ridotto il carico del database in diversi servizi e abbiamo avviato un failover RDS. Il team sta lavorando attivamente per ripristinare le normali prestazioni.
investigating
Abbiamo notato le prestazioni degradate in prod-us
Flussi come Pull Request o CLI scansione può essere più lento del solito
investigating
Il team sta attivamente lavorando con AWS e indagando su ciò che sembra essere un problema di failover del database che interessa l'ambiente statunitense.
Condivideremo un altro aggiornamento non appena avremo maggiori informazioni.
investigating
La piattaforma degli Stati Uniti sta migliorando in seguito all'esaurimento della connessione RDS/PostgreSQL precedente.
AWS ha confermato che l'istanza PostgreSQL originale è tornata a uno stato operativo, e stiamo vedendo le scansioni di PR essere nuovamente elaborati.
Il principale degrado rimanente è ritardato elaborazione GitHub-driven a causa di un ampio backlog webhook, che continua a drenare.
Continueremo a monitorare il recupero e fornire un altro aggiornamento come l'elaborazione ritorna alla normalità
investigating
Il sistema è tornato ad essere pienamente operativo
resolved
(2/2)
• Utilizzato i carichi di lavoro che stavano creando volumi elevati di operazioni di dati di breve durata, per ridurre il carico del database mentre gli eventi ritardati sono stati cancellati.
• Scansione delle richieste di estrazione che sono state perse durante l'incidente.
**4b. Articoli d'azione **
• Modificare la scrittura di grandi lotti di dati per ridurre il carico del database.
• Spostare il nostro carico di lavoro più alto volume nel proprio database dedicato, quindi un problema non può influenzare il resto della piattaforma.
• Aggiungi avvisi e monitoraggio più approfondito per l'utilizzo della connessione del database e la salute del database.
• Dare a ciascun servizio le proprie credenziali di database dedicate.
• Processare gli eventi in arrivo in modo più efficiente per accelerare il recupero dopo una rottura.
• Migliorare il monitoraggio dei ritardi di elaborazione e degli avvisi sugli eventi interni.
• Verificare la capacità del database e le impostazioni delle prestazioni per aggiungere più headroom.
resolved
(1/2)
Revisione:
Il 5 ottobre 2026, a partire dalle 15:55 IDT, i clienti della nostra piattaforma statunitense hanno visto risposte lente, errori intermittenti e ritardi nei controlli di richiesta e nelle scansioni CLI. Alcuni clienti i cui repository richiedono i controlli di richiesta Cycode pull non possono fondersi fino a quando la scansione non è ripresa.
Il problema è iniziato quando un processo di manutenzione di sfondo nel nostro database principale è caduto indietro e ha smesso di completare, e il database ha smesso di salvare nuovi dati. Il servizio di ripristino ha richiesto diverse ore perché il database standby prima ha dovuto elaborare un ampio backlog dei cambiamenti.
Il database era tornato e la piattaforma era disponibile di nuovo per 19:43 IDT. Elaborazione ritardata poi catturato, e l'incidente è stato risolto alle 23:24 IDT. Le richieste che sono state perse durante l'incidente sono state scansionate.
**2. Timeline chiave (IDT)**
** 5 ottobre 2026, 12:55 IDT**: Un processo di manutenzione del database di routine inizia a funzionare molto più lento del normale. Nessun impatto del cliente ancora.
** 5 ottobre 2026, 14:53 IDT**: Il prossimo ciclo di manutenzione inizia e non completa.
** 5 ottobre 2026, 15:55 IDT**: Il database smette di salvare nuovi dati e le prestazioni della piattaforma si degradano.
** 5 ottobre 2026, 16:03 IDT**: Il database raggiunge il suo limite di connessione. I clienti iniziano a vedere gli errori.
** 5 ottobre 2026, 16:21 IDT**: Incidente dichiarato e squadra di risposta impegnato.
** 5 ottobre 2026, 16:24 IDT**: Primo aggiornamento inviato alla pagina di stato.
** 5 ottobre 2026, 16:49 IDT**: Accendere il database standby.
** 5 ottobre 2026, 17:00 IDT**: caso di supporto aperto con il nostro provider di infrastrutture cloud.
** 5 ottobre 2026, 18:24 IDT**: Il percorso di recupero alternativo è iniziato in parallelo. Workaround pubblicato per i clienti bloccati dai controlli richiesti.
** 5 ottobre 2026, 19:43 IDT**: Database disponibile di nuovo, e Cycode API e Cycode Platform sono accessibili.
** 5 ottobre 2026, 19:54 IDT**: Riprendi la scansione della richiesta.
** 5 ottobre 2026, 20:20 IDT**: Capacità di elaborazione aumentata per chiari eventi ritardati.
** 5 ottobre 2026, 20:45 IDT**: I carichi di lavoro ad alto volume si sono fermati per ridurre il carico del database.
** 5 ottobre 2026, 21:56 IDT**: Estrarre le richieste perse durante l'incidente identificato e scansionato.
** 5 ottobre 2026, 23:09 IDT**: Tutti i servizi completamente operativi.
** 5 ottobre 2026, 23:24 IDT**: Incidente risolto.
**3. Causa radice **
Il nostro database esegue un processo di sfondo di routine che consente di salvare regolarmente le recenti modifiche allo storage permanente. Due condizioni hanno contribuito a questo processo rallentando:
• ** Operazioni di dati di breve durata ad alto volume:** alcuni dei nostri carichi di lavoro di elaborazione sono stati costantemente creando e rimuovendo un gran numero di strutture di dati di breve durata.
• **Una sincronizzazione di sfondo ritardata:** un processo di sincronizzazione dei dati era caduto molto indietro, che ha impedito al database di ripulirsi dopo se stesso.
Il processo di manutenzione ha rallentato e alla fine ha smesso di completare. Il database non poteva più salvare nuovi dati e le richieste iniziarono a fare la coda. I nostri servizi hanno rinnovato tali richieste e hanno aperto molte nuove connessioni, che hanno utilizzato la capacità di connessione del database. I clienti hanno visto questo come errori e risposte lente.
Siamo passati al nostro database standby. Prima che potesse servire il traffico, ha dovuto elaborare tutti i cambiamenti fatti dall'ultimo ciclo di manutenzione completato, circa quattro ore di attività. Questo ha esteso l'outage.
**4. Azioni prese**
• Riduzione del carico sul database mediante l'elaborazione temporaneamente non essenziale.
• Avviato un passaggio al database standby.
• Ha aperto un caso di supporto con il nostro provider di infrastrutture cloud e ha lavorato con loro su base escalata.
• Preparato un percorso di recupero alternativo in parallelo.
• Condivisione di una soluzione temporanea per i clienti bloccati dai controlli richiesti.
• Una volta recuperato il database, maggiore capacità di elaborazione per cancellare eventi ritardati.
investigating
L'ultimo backlog rimanente continua ad essere elaborato a ritmo costante.
Le nostre stime mostrano che il backlog delle ultime parti dovrebbe essere completamente elaborato in circa 60-90 minuti (20:30 UTC).
Vediamo la maggior parte delle scansioni di richiesta pull (60% al momento di questo aggiornamento) vengono completate in meno di 15 minuti. e questo numero è in costante crescita ad un ritmo costante.
Oltre a questo sistema sembra operativo.
Crediamo che l'applicazione/UI siano pienamente operativi.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Applicazione e scansione delle prestazioni degradate
Inizio 5 ottobre 2026 alle ore 13:24 UTC · 6h 59m
IssuesIncidente minore
investigating
Abbiamo notato le prestazioni degradate in prod-us
Flussi come Pull Request o CLI scansione può essere più lento del solito
investigating
Stiamo continuando a indagare su un grande degrado della piattaforma statunitense causata dalla esaurimento della connessione PostgreSQL. I clienti possono sperimentare tempi di risposta lenta, elevati 500 errori, e flussi di lavoro PR più lenti e scansioni CLI.
Abbiamo ridotto il carico del database in diversi servizi e abbiamo avviato un failover RDS. Il team sta lavorando attivamente per ripristinare le normali prestazioni.
investigating
Il team sta attivamente lavorando con AWS e indagando su ciò che sembra essere un problema di failover del database che interessa l'ambiente statunitense.
Condivideremo un altro aggiornamento non appena avremo maggiori informazioni.
investigating
La squadra continua a lavorare con AWS, che ha aumentato il problema internamente.
Parallelamente, stiamo lavorando per ripristinare la funzionalità spostandosi in un altro database.
Eventuali richieste di pull bloccate in attesa dello stato Cycode possono essere sbloccate rimuovendo le scansioni Cycode dai controlli previsti direttamente nel vostro SCM (Source Code Management). Raggiungi il tuo rappresentante Cycode per aiutarti a semplificare il processo.
investigating
AWS ha confermato che l'istanza PostgreSQL interessata è attualmente in uno stato di recupero interno.
Il failover Multi-AZ atteso non si è verificato come progettato, e AWS sta attivamente indagando perché.
Parallelamente, stiamo continuando a lavorare per ripristinare i servizi interessati utilizzando un percorso di database alternativo per accelerare il recupero
investigating
Stiamo vedendo la banca dati sta ripristinando le sue capacità operative.
Vediamo prima le scansioni di Pull Request in fase di elaborazione.
Stiamo monitorando il sistema e aumentando il throughput.
investigating
Il database rimane pienamente operativo.
Stiamo lavorando ad aumentare la velocità di elaborazione oltre regolarmente per elaborare tutti i backlog il prima possibile.
investigating
La piattaforma degli Stati Uniti sta migliorando in seguito all'esaurimento della connessione RDS/PostgreSQL precedente.
AWS ha confermato che l'istanza PostgreSQL originale è tornata a uno stato operativo, e stiamo vedendo le scansioni di PR essere nuovamente elaborati.
Il principale degrado rimanente è ritardato elaborazione GitHub-driven a causa di un ampio backlog webhook, che continua a drenare.
Continueremo a monitorare il recupero e fornire un altro aggiornamento come l'elaborazione ritorna alla normalità
investigating
L'ultimo backlog rimanente continua ad essere elaborato a ritmo costante.
Le nostre stime mostrano che il backlog delle ultime parti dovrebbe essere completamente elaborato in circa 60-90 minuti (20:30 UTC).
Vediamo la maggior parte delle scansioni di richiesta pull (60% al momento di questo aggiornamento) vengono completate in meno di 15 minuti. e questo numero è in costante crescita ad un ritmo costante.
Oltre a questo sistema sembra operativo.
Crediamo che l'applicazione/UI siano pienamente operativi.
investigating
Il sistema è tornato ad essere pienamente operativo
resolved
Revisione:
Il 5 ottobre 2026, a partire dalle 15:55 IDT, i clienti della nostra piattaforma statunitense hanno visto risposte lente, errori intermittenti e ritardi nei controlli di richiesta e nelle scansioni CLI. Alcuni clienti i cui repository richiedono i controlli di richiesta Cycode pull non possono fondersi fino a quando la scansione non è ripresa.
Il problema è iniziato quando un processo di manutenzione di sfondo nel nostro database principale è caduto indietro e ha smesso di completare, e il database ha smesso di salvare nuovi dati. Il servizio di ripristino ha richiesto diverse ore perché il database standby prima ha dovuto elaborare un ampio backlog dei cambiamenti.
Il database era tornato e la piattaforma era disponibile di nuovo per 19:43 IDT. Elaborazione ritardata poi catturato, e l'incidente è stato risolto alle 23:24 IDT. Le richieste che sono state perse durante l'incidente sono state scansionate.
**2. Timeline chiave (IDT)**
** 5 ottobre 2026, 12:55 IDT**: Un processo di manutenzione del database di routine inizia a funzionare molto più lento del normale. Nessun impatto del cliente ancora.
** 5 ottobre 2026, 14:53 IDT**: Il prossimo ciclo di manutenzione inizia e non completa.
** 5 ottobre 2026, 15:55 IDT**: Il database smette di salvare nuovi dati e le prestazioni della piattaforma si degradano.
** 5 ottobre 2026, 16:03 IDT**: Il database raggiunge il suo limite di connessione. I clienti iniziano a vedere gli errori.
** 5 ottobre 2026, 16:21 IDT**: Incidente dichiarato e squadra di risposta impegnato.
** 5 ottobre 2026, 16:24 IDT**: Primo aggiornamento inviato alla pagina di stato.
** 5 ottobre 2026, 16:49 IDT**: Accendere il database standby.
** 5 ottobre 2026, 17:00 IDT**: caso di supporto aperto con il nostro provider di infrastrutture cloud.
** 5 ottobre 2026, 18:24 IDT**: Il percorso di recupero alternativo è iniziato in parallelo. Workaround pubblicato per i clienti bloccati dai controlli richiesti.
** 5 ottobre 2026, 19:43 IDT**: Database disponibile di nuovo, e Cycode API e Cycode Platform sono accessibili.
** 5 ottobre 2026, 19:54 IDT**: Riprendi la scansione della richiesta.
** 5 ottobre 2026, 20:20 IDT**: Capacità di elaborazione aumentata per chiari eventi ritardati.
** 5 ottobre 2026, 20:45 IDT**: I carichi di lavoro ad alto volume si sono fermati per ridurre il carico del database.
** 5 ottobre 2026, 21:56 IDT**: Estrarre le richieste perse durante l'incidente identificato e scansionato.
** 5 ottobre 2026, 23:09 IDT**: Tutti i servizi completamente operativi.
** 5 ottobre 2026, 23:24 IDT**: Incidente risolto.
**3. Causa radice **
Il nostro database esegue un processo di sfondo di routine che consente di salvare regolarmente le recenti modifiche allo storage permanente. Due condizioni hanno contribuito a questo processo rallentando:
• ** Operazioni di dati di breve durata ad alto volume:** alcuni dei nostri carichi di lavoro di elaborazione sono stati costantemente creando e rimuovendo un gran numero di strutture di dati di breve durata.
• **Una sincronizzazione di sfondo ritardata:** un processo di sincronizzazione dei dati era caduto molto indietro, che ha impedito al database di ripulirsi dopo se stesso.
Il processo di manutenzione ha rallentato e alla fine ha smesso di completare. Il database non poteva più salvare nuovi dati e le richieste iniziarono a fare la coda. I nostri servizi hanno rinnovato tali richieste e hanno aperto molte nuove connessioni, che hanno utilizzato la capacità di connessione del database. I clienti hanno visto questo come errori e risposte lente.
Siamo passati al nostro database standby. Prima che potesse servire il traffico, ha dovuto elaborare tutti i cambiamenti fatti dall'ultimo ciclo di manutenzione completato, circa quattro ore di attività. Questo ha esteso l'outage.
**4. Azioni prese**
• Riduzione del carico sul database mediante l'elaborazione temporaneamente non essenziale.
• Avviato un passaggio al database standby.
• Ha aperto un caso di supporto con il nostro provider di infrastrutture cloud e ha lavorato con loro su base escalata.
• Preparato un percorso di recupero alternativo in parallelo.
• Condivisione di una soluzione temporanea per i clienti bloccati dai controlli richiesti.
• Una volta recuperato il database, maggiore capacità di elaborazione per cancellare eventi ritardati.
• Utilizzato i carichi di lavoro che stavano creando volumi elevati di operazioni di dati di breve durata, per ridurre il carico del database mentre gli eventi ritardati sono stati cancellati.
• Scansione delle richieste di estrazione che sono state perse durante l'incidente.
**4b. Articoli d'azione **
• Modificare la scrittura di grandi lotti di dati per ridurre il carico del database.
• Spostare il nostro carico di lavoro più alto volume nel proprio database dedicato, quindi un problema non può influenzare il resto della piattaforma.
• Aggiungi avvisi e monitoraggio più approfondito per l'utilizzo della connessione del database e la salute del database.
• Dare a ciascun servizio le proprie credenziali di database dedicate.
• Processare gli eventi in arrivo in modo più efficiente per accelerare il recupero dopo una rottura.
• Migliorare il monitoraggio dei ritardi di elaborazione e degli avvisi sugli eventi interni.
• Verificare la capacità del database e le impostazioni delle prestazioni per aggiungere più headroom.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Disturbo del servizio di autenticazione
Inizio 28 settembre 2026 alle ore 20:45 UTC · 0m
IssuesIncidente minore
monitoring
Alle 14:00 PM EDT (18:00 UTC), abbiamo identificato un significativo picco di carico che interessa il database di autenticazione. Per mitigare il problema, abbiamo eseguito un aggiornamento delle istanze. Una breve interruzione delle connessioni del database potrebbe essere avvenuta durante l'aggiornamento. La piattaforma è stabile e continuiamo a monitorare attentamente la situazione.
resolved
Il sistema è completamente operativo, senza problemi in corso osservati. Questo incidente è ora risolto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Disturbo del servizio di autenticazione
Inizio 28 settembre 2026 alle ore 19:08 UTC · 1h 38m
IssuesIncidente minore
monitoring
Alle 14:00 PM EDT (18:00 UTC), abbiamo identificato un significativo picco di carico che interessa il database di autenticazione. Per mitigare il problema, abbiamo eseguito un aggiornamento delle istanze. Una breve interruzione delle connessioni del database potrebbe essere avvenuta durante l'aggiornamento. La piattaforma è stabile e continuiamo a monitorare attentamente la situazione.
resolved
Il sistema è completamente operativo, senza problemi in corso osservati. Questo incidente è ora risolto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
GitHub incidente può influenzare Cycode
Inizio 13 settembre 2026 alle ore 18:53 UTC · 0m
IssuesIncidente minore
resolved
Risolto
investigating
Componente GitHub: Pull Requests Original GitHub:
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
GitHub incidente può influenzare Cycode
Inizio 13 settembre 2026 alle ore 18:53 UTC · 0m
IssuesIncidente minore
investigating
Componente GitHub: Pull Requests Original GitHub:
resolved
Risolto
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
GitHub incidente può influenzare Cycode
Inizio 13 settembre 2026 alle ore 10:36 UTC · 8h 17m
IssuesIncidente minore
investigating
Componente GitHub: Pull Requests Original GitHub:
resolved
Risolto
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Applicazione e scansione delle prestazioni degradate
Inizio 8 settembre 2026 alle ore 17:26 UTC · 0m
IssuesIncidente minore
resolved
MemoriaDB metriche sono stabili, il ritardo di elaborazione è recuperato, e il sistema è ora completamente operativo.
monitoring
Abbiamo osservato un forte picco nell'utilizzo della memoria MemoryDB in prod-us, compreso l'utilizzo di swap attivo.
La mitigazione è stata applicata. MemoriaDB metriche sono rimaste stabili da allora, e il ritardo di elaborazione sta diminuendo rapidamente
investigating
Abbiamo notato le prestazioni degradate in prod-us
Flussi come Pull Request o CLI scansione può essere più lento del solito
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Applicazione e scansione delle prestazioni degradate
Inizio 8 settembre 2026 alle ore 16:53 UTC · 33m
IssuesIncidente minore
investigating
Abbiamo notato le prestazioni degradate in prod-us
Flussi come Pull Request o CLI scansione può essere più lento del solito
monitoring
Abbiamo osservato un forte picco nell'utilizzo della memoria MemoryDB in prod-us, compreso l'utilizzo di swap attivo.
La mitigazione è stata applicata. MemoriaDB metriche sono rimaste stabili da allora, e il ritardo di elaborazione sta diminuendo rapidamente
resolved
MemoriaDB metriche sono stabili, il ritardo di elaborazione è recuperato, e il sistema è ora completamente operativo.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Applicazione e scansione delle prestazioni degradate
Inizio 8 settembre 2026 alle ore 10:52 UTC · 0m
IssuesIncidente minore
investigating
Abbiamo notato le prestazioni degradate in prod-eu.
Il degrado delle prestazioni colpisce tutte le applicazioni e tutti i flussi (**come Pull Request o CLI scansione**) possono essere più lenti del solito.
La nostra indagine iniziale suggerisce un carico eccessivo sul database condiviso, rendendo la lettura e la scrittura a esso più lento.
La squadra continua a indagare.
resolved
Il sistema è tornato ad essere pienamente operativo.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Applicazione e scansione delle prestazioni degradate
Inizio 8 settembre 2026 alle ore 09:53 UTC · 58m
IssuesIncidente minore
investigating
Abbiamo notato le prestazioni degradate in prod-eu.
Il degrado delle prestazioni colpisce tutte le applicazioni e tutti i flussi (**come Pull Request o CLI scansione**) possono essere più lenti del solito.
La nostra indagine iniziale suggerisce un carico eccessivo sul database condiviso, rendendo la lettura e la scrittura a esso più lento.
La squadra continua a indagare.
resolved
Il sistema è tornato ad essere pienamente operativo.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
