Alguns usuários podem ver tempos de espera aumentados para trabalhos do Docker gen2 devido a problemas de capacidade.
identified
Estamos adicionando capacidade adicional para ajudar a mitigar o problema. Nota: Ainda estamos vendo atrasos até 20 minutos em 2xlarge.
identified
Tempos de espera para 2xlarge docker trabalhos estão se recuperando. Continuaremos a atualizar à medida que a capacidade estiver online.
identified
Tempos de espera para 2xlarge docker trabalhos são agora menos de 60 segundos.
Os tempos de espera para outros tamanhos de recursos não foram impactados por este incidente e permanecem abaixo de 10 segundos.
monitoring
Vimos uma recuperação total dos tempos de espera para trabalhos de docker.
resolved
Tempos de espera para trabalhos do Docker gen2 foram recuperados e trabalhos estão em execução dentro dos tempos de espera normais.
postmortem
# # Resumo
De 15:44 para 20:55 UTC em 21 de outubro, os clientes que executam trabalhos do Docker Gen 2 viram tempos de espera aumentados para seus trabalhos começar. Os atrasos foram mais longos na classe de recursos 2xlarge, onde os trabalhos esperaram até 20 minutos. O incidente foi causado pela disponibilidade limitada das instâncias de nuvem que configurámos para atender à demanda, particularmente para 2xlarge jobs.
Em resposta, nossa equipe de engenharia configurou tipos de instância adicionais, configurou clusters de Docker Gen 2 adicionais. Em 20:55 UTC, os tempos de espera retornaram ao normal e o incidente foi resolvido.
Depois que o incidente foi resolvido, expandimos nossa frota de Dockers Gen 2 para regiões de nuvem adicionais, e continuamos ativamente levantando regiões de nuvem adicionais para evitar incidentes semelhantes no futuro.
A página de status original pode ser encontrada aqui: [21 de outubro - Aumentado Docker gen2 espera times](https://status.circleci.com/incidents/5jb50gh55gtj).
# # Fundo
Quando o CircleCI executa uma tarefa do Docker, nós a programamos em um dos vários clusters de instâncias na nuvem, e cada instância é capaz de executar vários trabalhos isolados. Scheduling a job on a cloud instance is a classic [“bin shacking problem”](https://en.wikipedia.org/wiki/Bin packing problem): finding available capacidade que se encaixa na classe de recursos solicitados CPU, memória e armazenamento. Classes de recursos maiores como 2xlarge são mais difíceis de caber do que as menores, que se juntam mais firmemente.
Nós fornecemos instâncias de nuvem usando uma lista de tipos de instância classificados. Se o provedor de nuvem não pode fornecer nossa primeira escolha, voltamos ao próximo tipo da lista. Mantemos ainda um tamanho mínimo da frota: um número mínimo de instâncias continua em funcionamento, para que não desistamos da capacidade quando a procura é baixa. Acima desse tamanho mínimo de frota, adicionamos instâncias à medida que a demanda aumenta.
Quando não há capacidade suficiente para executar uma carga de trabalho, nós fila que funciona até que a capacidade fique disponível.
# # O Que Aconteceu
\(Todas as vezes UTC\)
A partir das 15:44 de 21 de outubro, a procura da classe de recursos Gen 2 2xlarge aumentou acentuadamente, e nós não fornecemos capacidade adicional rapidamente o suficiente para acompanhar. A nossa equipa de engenharia começou a investigar. Em 19:25, os tempos de espera para a classe de recursos Gen 2 2xlarge tinham atingido 20 minutos, e os tempos de espera para outras classes de recursos tinham aumentado também.
Em 19:56, nossa equipe de engenharia tinha configurado outros tipos de instância para a frota Gen 2, a fim de obter mais capacidade online, e em 19:59, estávamos fornecendo esses tipos de instância. Às 20:11, adicionamos vários clusters adicionais de Gen 2, e aumentamos o tamanho mínimo da frota nesses clusters.
Em 20:35, o número de trabalhos em fila voltou aos níveis normais, e em 20:41, 95% dos 2xlarge jobs estavam começando em 4 segundos. Resolvemos o incidente às 20:55.
Depois de resolver esse incidente, adicionamos regiões de nuvem adicionais para trabalhos do Docker para disponibilizar mais capacidade.
# # Prevenção futura e melhoria do processo
Já tomamos as seguintes medidas para melhorar os tempos de início do trabalho, incluindo a capacidade de abastecimento de mais lugares, reservando mais capacidade para grandes classes de recursos e implementação de provisionamento mais rápido.
** Nós adicionamos regiões adicionais para trabalhos de Docker. ** Recentemente adicionamos regiões de nuvem adicionais para trabalhos de máquinas, e agora fizemos o mesmo para trabalhos de Docker.
** Continuaremos ativamente adicionando regiões de nuvem adicionais para trabalhos de Docker e Machine**.
** Nós adicionamos clusters adicionais de Gen 2**. Nós configuramos vários clusters adicionais de Gen 2 para agendar trabalhos mais rapidamente, e para disponibilizar mais capacidade total.
** Expandimos o conjunto de tipos de instância de nuvem que usamos e elevamos nosso tamanho mínimo de frota.** Nós configuramos tipos de instância adicionais. Também elevámos o tamanho mínimo da frota para a geração 2 satisfazer a atual demanda de base.
** Modificamos nosso agendador de tarefas para priorizar o agendamento de classes de recursos maiores.** Nós mudamos a forma como agendamos trabalhos para equilibrar os tempos de espera de forma mais justa entre as classes de recursos, e para tarefas de bin-pack mais eficientemente em instâncias disponíveis.
# # Conclusão
A experiência do cliente é nossa principal prioridade, e nos comprometemos a melhorar continuamente a confiabilidade de nossos sistemas para corresponder à confiança que nossos clientes depositam em nós. Agradecemos aos nossos clientes pela sua paciência enquanto a nossa equipa trabalhou para resolver este incidente.
Por favor, contacte a nossa equipa de apoio com quaisquer perguntas ou preocupações.
Traduzido automaticamente da atualização oficial do incidente.
Aumento dos tempos de espera para trabalhos macOS em m4pro.large
Início 20 Here 2026 da 15:58 UTC · 2h 16m
IssuesMinor incident
Componentes afetados
macOS Jobs
investigating
Estamos vendo tempos de espera aumentados para alguns trabalhos do macOS usando a classe de recursos m4pro.large. Estamos a investigar e vamos fornecer outra actualização em breve. Obrigado pela vossa paciência.
monitoring
Os clientes que executam trabalhos do macOS na classe de recursos m4pro.large ainda estão vendo tempos de espera aumentados, com alguns trabalhos esperando até 30 minutos para começar. Continuamos a monitorizar isto e vamos partilhar outra actualização em breve.
monitoring
Tempos de espera para m4pro.large ainda estão elevados devido à grande demanda. Todos m4pro.medium são normais. Estamos a monitorizar ativamente, apreciamos a paciência.
monitoring
Tempos de espera para trabalhos macOS na classe de recursos m4pro.large estão se recuperando. Trabalhos usando o Xcode 27.0 estão agora esperando cerca de ~3.5 minutos em média, para baixo de cerca de ~40 minutos no pico. Trabalhos usando Xcode 26.6 e 26.4.1 ainda estão trabalhando através de um backlog, que está limpando. Os tempos de espera no m4pro.medium são normais. Iremos partilhar outra actualização assim que continuarmos a monitorizar.
resolved
Tempos de espera para trabalhos macOS na classe de recursos m4pro.large retornaram ao normal. Agradecemos-lhe pela sua paciência enquanto os atrasos foram limpos.
Traduzido automaticamente da atualização oficial do incidente.
Atrasa o início de tarefas do macOS que usam o Xcode 26.6.0
Início 14 Here 2026 da 14:47 UTC · 1h 13m
IssuesMinor incident
Componentes afetados
macOS Jobs
investigating
Desde aproximadamente 14:00 UTC, clientes executando trabalhos do macOS que usam o Xcode 26.6.0 na classe de recursos M4 Pro estão passando por atrasos ao iniciar trabalhos. Os tempos de espera chegaram a 30 minutos ou mais.
Obrigado pela sua paciência enquanto os nossos engenheiros investigam. Nós forneceremos outra atualização até 15:30 UTC.
identified
Atrasos no início das tarefas do macOS que usam o Xcode 26.6.0 foram recuperados. Desde aproximadamente 15:11 UTC, trabalhos do macOS que usam o Xcode 26.4 estão passando por atrasos começando, com tempos de espera de cerca de 30 minutos.
Obrigado por sua paciência enquanto nossos engenheiros trabalham para resolver isso. Vamos fornecer outra atualização até 15:45 UTC.
resolved
Entre aproximadamente 14:00 UTC e 15:51 UTC em 14 de outubro, clientes executando trabalhos do macOS que usam Xcode 26.6.0 ou Xcode 26.4 experimentaram atrasos em iniciar trabalhos. A partir de aproximadamente 14:00 UTC, trabalhos que usam Xcode 26.6.0 na classe M4 Pro grande recurso esperou 30 minutos ou mais para começar, e esses atrasos recuperados em aproximadamente 15:12 UTC. De aproximadamente 15:11 UTC, trabalhos que usam Xcode 26.4 esperaram cerca de 30 minutos para começar.
O problema foi resolvido e toda a funcionalidade afetada voltou ao normal. Agradecemos a sua paciência, enquanto nossa equipe trabalhou na implementação de uma correção.
Traduzido automaticamente da atualização oficial do incidente.
Atraso nos dados que aparecem em UI e API
Início 9 Here 2026 da 11:33 UTC · 14h 36m
OutageMajor incident
Componentes afetados
CircleCI APICircleCI UI
identified
Há um atraso em nossa infraestrutura de dados causando atrasos antes de construir dados e algumas notificações se tornam visíveis. Estamos a trabalhar numa mitigação.
identified
O que é impactado:
Clientes acionando oleodutos, e clientes confiando em webhooks de saída e email e notificações Slack.
O que você pode esperar
Desde 11:15 UTC:
- Pipelines ainda estão sendo criados enquanto isso está em curso, mas ainda não processado, então o retrigger pode resultar em duplicidade de pipelines.
- Os webhooks de saída e as notificações transacionais (Slack e email) não estão sendo enviados.
- O estado dos tubos pode não estar visível.
- Dados de cobrança de uso na página Uso do Projeto serão obsoletos.
Obrigado por sua paciência enquanto nossos engenheiros trabalham para resolver isso.
Próxima atualização:
Nós forneceremos outra atualização até 13:30 UTC.
identified
Entre 11:15 UTC e cerca de 13:00 UTC, pipelines foram criados, mas não processados, e webhooks de saída e notificações transacionais (Slack e email) não foram enviados.
O que é impactado:
Clientes acionando oleodutos, e clientes confiando em webhooks de saída e email e notificações Slack.
O que você pode esperar:
- Desde as 13:00 UTC, os gasodutos estão a ser processados novamente e os trabalhos estão a começar.
- A maioria dos trabalhos estão começando em cerca de 4 minutos, e alguns estão esperando até cerca de 10 minutos. Os tubos acionados durante o incidente ainda estão sendo processados e podem levar mais tempo para começar.
- Os webhooks e as notificações foram retomadas.
- Pipelines ainda estão sendo processados a partir do backlog, então o retriggering pode resultar em duplicidade pipelines.
Obrigado por sua paciência enquanto nossos engenheiros trabalham para resolver isso.
Próxima atualização:
Nós forneceremos outra atualização até 14:00 UTC.
identified
Desde 11:15 UTC, os clientes têm experimentado a interrupção de pipelines e notificações. Entre 11:15 UTC e cerca de 13:00 UTC, pipelines foram criados, mas não processados, e webhooks de saída e notificações transacionais (Slack e email) não foram enviados.
O que está impactado
Clientes executando fluxos de trabalho e trabalhos, e clientes visualizando dados de uso na página Uso do Projeto.
O que você pode esperar
- Os tubos estão a ser processados de novo, incluindo os desencadeados durante o incidente.
- Desde cerca de 13:25 UTC, fluxos de trabalho e trabalhos têm começado com atrasos crescentes como trabalhamos através do backlog. A maioria dos trabalhos estão começando atualmente em cerca de 10 minutos, e alguns estão esperando até cerca de 25 minutos.
- Esperamos passar por este atraso por volta das 14:35 UTC.
- Fluxos de trabalho de pipelines acionados durante o incidente ainda estão esperando para começar, então o retriggering pode resultar em fluxos de trabalho duplicados.
- Os dados de cobrança de uso na página de Uso do Projeto estão atualmente obsoletos.
Obrigado por sua paciência enquanto nossos engenheiros trabalham para resolver isso.
Próxima atualização
Nós forneceremos outra atualização até 14:30 UTC.
identified
Desde 11:15 UTC, os clientes têm experimentado a interrupção de pipelines e notificações. Entre 11:15 UTC e cerca de 13:00 UTC, pipelines foram criados, mas não processados, e webhooks de saída e notificações transacionais (Slack e email) não foram enviados.
O que está impactado
Clientes executando fluxos de trabalho e trabalhos, e clientes visualizando dados de uso na página Uso do Projeto.
O que você pode esperar
- Atrasos ao iniciar fluxos de trabalho e trabalhos estão melhorando. A maioria dos trabalhos estão começando agora em cerca de 3 minutos, para baixo de cerca de 10 minutos às 13:50 UTC.
- Alguns fluxos de trabalho de gasodutos desencadeados durante o incidente ainda estão à espera de cerca de 40 minutos para começar.
- Trabalhar através do atraso está a demorar um pouco mais do que o esperado. Esperamos agora esvaziá-lo por volta das 14:45 UTC.
- Fluxos de trabalho de pipelines acionados durante o incidente ainda estão esperando para começar, então o retriggering pode resultar em fluxos de trabalho duplicados.
- Os dados de cobrança de uso na página de Uso do Projeto estão atualmente obsoletos.
Obrigado por sua paciência enquanto nossos engenheiros trabalham para resolver isso.
Próxima atualização
Nós forneceremos outra atualização até 15:00 UTC.
identified
Desde 11:15 UTC, os clientes têm experimentado a interrupção de pipelines e notificações. Entre 11:15 UTC e cerca de 13:00 UTC, pipelines foram criados, mas não processados, e webhooks de saída e notificações transacionais (Slack e email) não foram enviados. Entre cerca de 13:00 UTC e 14:40 UTC, fluxos de trabalho e trabalhos começaram com atrasos enquanto trabalhamos através do backlog.
O que está impactado
Clientes executando fluxos de trabalho e trabalhos, e clientes visualizando dados de uso na página Uso do Projeto.
O que você pode esperar
- O atraso dos fluxos de trabalho dos gasodutos desencadeados durante o incidente limpo às 14:40 UTC.
- A maioria dos trabalhos estão começando agora em cerca de 30 segundos, e alguns estão esperando até cerca de 3 minutos.
- Os dados de cobrança de uso na página de Uso do Projeto estão atualmente obsoletos.
Obrigado por sua paciência, enquanto nossos engenheiros continuam a trabalhar no problema subjacente.
Próxima atualização
Nós forneceremos outra atualização até 15:10 UTC.
monitoring
Desde 11:15 UTC, os clientes têm experimentado a interrupção de pipelines e notificações. Entre 11:15 UTC e cerca de 13:00 UTC, pipelines foram criados, mas não processados, e webhooks de saída e notificações transacionais (Slack e email) não foram enviados. Entre cerca de 13:00 UTC e 14:40 UTC, fluxos de trabalho e trabalhos começaram com atrasos enquanto trabalhamos através do backlog.
O que está impactado
Clientes executando fluxos de trabalho e trabalhos, e clientes visualizando dados de uso na página Uso do Projeto.
O que você pode esperar
- O atraso dos gasodutos e fluxos de trabalho do incidente foi apagado.
- Desde cerca de 14:45 UTC, a maioria dos fluxos de trabalho e trabalhos estão começando em cerca de 15 segundos, e os horários de início estão continuando a voltar ao normal.
- Os dados de cobrança de uso na página de Uso do Projeto estão atualmente obsoletos.
Obrigado por sua paciência enquanto nossos engenheiros monitoram a recuperação.
Próxima atualização
Nós forneceremos outra atualização até 15:20 UTC.
monitoring
Desde 11:15 UTC, os clientes têm experimentado a interrupção de pipelines e notificações. Entre 11:15 UTC e cerca de 13:00 UTC, pipelines foram criados, mas não processados, e webhooks de saída e notificações transacionais (Slack e email) não foram enviados. Entre cerca de 13:00 UTC e 14:40 UTC, fluxos de trabalho e trabalhos começaram com atrasos enquanto trabalhamos através do backlog.
O que está impactado
Clientes visualizando pipelines, fluxos de trabalho e trabalhos na UI CircleCI e clientes visualizando dados de uso na página Uso do Projeto.
O que você pode esperar
Os fluxos de trabalho e os empregos estão a correr a tempo.
A UI CircleCI está 30 minutos atrasada. Novos fluxos de trabalho e mudanças de status podem demorar tanto para aparecer.
Os nossos engenheiros estão a trabalhar para acelerar o processamento para que a UI possa recuperar.
- Evite retriggering workflows que ainda não aparecem na UI, pois isso pode criar duplicatas.
- Os dados de cobrança de uso na página de Uso do Projeto estão atualmente obsoletos.
Obrigado por sua paciência enquanto nossos engenheiros trabalham para reduzir esse atraso.
Próxima atualização
Nós forneceremos outra atualização até 16:00 UTC.
monitoring
Desde 11:15 UTC, os clientes têm experimentado a interrupção de pipelines e notificações. Entre 11:15 UTC e cerca de 13:00 UTC, pipelines foram criados, mas não processados, e webhooks de saída e notificações transacionais (Slack e email) não foram enviados. Entre cerca de 13:00 UTC e 14:40 UTC, fluxos de trabalho e trabalhos começaram com atrasos enquanto trabalhamos através do backlog.
O que está impactado
Clientes executando fluxos de trabalho e empregos, clientes visualizando pipelines, fluxos de trabalho e trabalhos na UI CircleCI e clientes visualizando dados de uso na página Uso do Projeto.
O que você pode esperar
- Desde cerca de 15:15 UTC, fluxos de trabalho e trabalhos têm começado com atrasos crescentes. A maioria dos empregos estão começando atualmente em cerca de 4 minutos, e alguns estão esperando até cerca de 20 minutos.
- A UI CircleCI permanece cerca de 30 minutos atrasada em média, e algumas atualizações estão a demorar mais. Novos fluxos de trabalho e mudanças de status podem demorar tanto para aparecer.
- Evite retriggering workflows que ainda não aparecem na UI, pois isso pode criar duplicatas.
- Os dados de cobrança de uso na página de Uso do Projeto estão atualmente obsoletos.
Obrigado por sua paciência enquanto nossos engenheiros trabalham para reduzir esses atrasos.
Próxima atualização
Vamos fornecer outra atualização até 16:30 UTC.
monitoring
Desde 11:15 UTC, os clientes têm experimentado a interrupção de pipelines e notificações. Entre 11:15 UTC e cerca de 13:00 UTC, pipelines foram criados, mas não processados, e webhooks de saída e notificações transacionais (Slack e email) não foram enviados. Entre cerca de 13:00 UTC e 14:40 UTC, fluxos de trabalho e trabalhos começaram com atrasos enquanto trabalhamos através do backlog. Desde cerca de 15:15 UTC, fluxos de trabalho e trabalhos têm começado novamente com atrasos.
O que está impactado
Clientes executando fluxos de trabalho e empregos, clientes visualizando pipelines, fluxos de trabalho e trabalhos na UI CircleCI e clientes visualizando dados de uso na página Uso do Projeto.
O que você pode esperar
- Atrasos ao iniciar fluxos de trabalho e trabalhos pararam de aumentar e estão começando a facilitar. A maioria dos empregos estão começando em cerca de 4 minutos, e alguns estão esperando até cerca de 25 minutos.
- A UI CircleCI está 20 minutos atrasada, de 30 minutos. Novos fluxos de trabalho e mudanças de status podem demorar tanto para aparecer.
- Evite retriggering workflows que ainda não aparecem na UI, pois isso pode criar duplicatas.
- Os dados de cobrança de uso na página de Uso do Projeto estão atualmente obsoletos.
Obrigado por sua paciência enquanto nossos engenheiros trabalham para reduzir esses atrasos.
Próxima atualização
Nós forneceremos outra atualização até 17:00 UTC.
monitoring
Desde 11:15 UTC, os clientes têm experimentado a interrupção de pipelines e notificações. Entre 11:15 UTC e cerca de 13:00 UTC, pipelines foram criados, mas não processados, e webhooks de saída e notificações transacionais (Slack e email) não foram enviados. Entre cerca de 13:00 UTC e 14:40 UTC, fluxos de trabalho e trabalhos começaram com atrasos enquanto trabalhamos através do backlog. Desde cerca de 15:15 UTC, fluxos de trabalho e trabalhos têm começado novamente com atrasos.
O que está impactado
Clientes executando fluxos de trabalho e empregos, clientes visualizando pipelines, fluxos de trabalho e trabalhos na UI CircleCI e clientes visualizando dados de uso na página Uso do Projeto.
O que você pode esperar
- Atrasos no início dos fluxos de trabalho e trabalhos mantêm-se estáveis. A maioria dos trabalhos estão começando em cerca de 4 minutos, e alguns estão esperando até cerca de 8 minutos, para baixo de cerca de 25 minutos.
A UI CircleCI permanece 20 minutos atrasada em média, e algumas atualizações estão a demorar mais. Novos fluxos de trabalho e mudanças de status podem demorar tanto para aparecer.
- Por favor, evite retriggering fluxos de trabalho que ainda não aparecem na UI, pois isso pode criar duplicatas.
- Os dados de cobrança de uso na página de Uso do Projeto estão atualmente obsoletos.
Obrigado por sua paciência enquanto nossos engenheiros trabalham para reduzir esses atrasos.
Próxima atualização
Nós forneceremos outra atualização até 17:30 UTC.
identified
Desde 11:15 UTC, os clientes têm experimentado a interrupção de pipelines e notificações. Entre 11:15 UTC e cerca de 13:00 UTC, pipelines foram criados, mas não processados, e webhooks de saída e notificações transacionais (Slack e email) não foram enviados. Entre cerca de 13:00 UTC e 14:40 UTC, fluxos de trabalho e trabalhos começaram com atrasos enquanto trabalhamos através do backlog. Desde cerca de 15:15 UTC, fluxos de trabalho e trabalhos têm começado novamente com atrasos.
O que está impactado
Clientes acionando pipelines e executando fluxos de trabalho e empregos, clientes visualizando pipelines, fluxos de trabalho e empregos na UI CircleCI e clientes visualizando dados de uso na página Uso do Projeto.
O que você pode esperar
- Desde as 17:00 UTC, os atrasos aumentaram significativamente. A maioria dos empregos está agora a demorar cerca de 12 minutos para começar, e alguns estão à espera de cerca de 30 minutos.
- Desde 17:15 UTC, alguns trabalhos não começam.
- Os tubos estão a ser processados mais lentamente, por isso alguns podem demorar mais tempo a começar.
- A UI do CircleCI está atrasada. Novos fluxos de trabalho e mudanças de status podem demorar tanto para aparecer.
- Por favor, evite retriggering fluxos de trabalho que ainda não aparecem na UI, pois isso pode criar duplicatas.
- Os dados de cobrança de uso na página de Uso do Projeto estão atualmente obsoletos.
Obrigado por sua paciência enquanto nossos engenheiros trabalham para resolver isso.
Próxima atualização
Nós forneceremos outra atualização até 18:00 UTC.
identified
Desde 11:15 UTC, os clientes têm experimentado a interrupção de pipelines e notificações. Entre 11:15 UTC e cerca de 13:00 UTC, pipelines foram criados, mas não processados, e webhooks de saída e notificações transacionais (Slack e email) não foram enviados. Entre cerca de 13:00 UTC e 14:40 UTC, fluxos de trabalho e trabalhos começaram com atrasos enquanto trabalhamos através do backlog. Desde cerca de 15:15 UTC, fluxos de trabalho e trabalhos têm começado novamente com atrasos.
O que está impactado
Clientes acionando pipelines e executando fluxos de trabalho e empregos, clientes visualizando pipelines, fluxos de trabalho e empregos na UI CircleCI e clientes visualizando dados de uso na página Uso do Projeto.
O que esperar
- Desde as 17:00 UTC, vemos um aumento de atrasos. A maioria dos empregos leva agora cerca de 25 minutos para começar, e alguns estão esperando até cerca de uma hora.
- Desde por volta das 17:15 UTC, alguns fluxos de trabalho em andamento falharam e um pequeno número de tarefas estão falhando em iniciar.
- Os novos gasodutos estão em fila e estão a demorar mais.
- A UI do CircleCI está atrasada. Novos fluxos de trabalho e mudanças de status podem demorar tanto para aparecer.
- Evite retriggering workflows que ainda não aparecem na UI, pois isso pode criar duplicatas.
- Os dados de cobrança de uso na página de Uso do Projeto estão atualmente obsoletos.
Nossos engenheiros continuam trabalhando para resolver o problema em questão.
Próxima atualização
Nós forneceremos outra atualização até 18:30 UTC.
identified
O que mudou desde a nossa última atualização
* A UI CircleCI está cerca de uma hora atrasada, e até cerca de 90 minutos para algumas atualizações. Fluxos de trabalho e trabalhos podem já ter sido executados, ou podem estar em execução, mesmo se a UI mostra-los como não iniciado ou não mostrá-los em tudo.
* Trabalhos que estão em execução estão começando mais rápido. A maioria agora está começando em cerca de 15 minutos, para baixo de cerca de 28 minutos, embora alguns ainda estão esperando mais de uma hora.
* Novos oleodutos são cada vez mais atrasados.
* Alguns fluxos de trabalho ainda estão falhando. Fluxos de trabalho que não puderam ser processados no tempo estão sendo marcados como falhou.
* Por favor, evite retriggering fluxos de trabalho que ainda não aparecem na UI, pois isso pode criar duplicatas.
Ainda em curso:
Dados de carga de uso na página de Uso do Projeto estão obsoletos.
Próxima atualização
Nós forneceremos outra atualização até 19:00 UTC.
identified
O que mudou desde a nossa última atualização
* Empregos estão começando mais rápido. A maioria agora está começando em cerca de 8 minutos, para baixo de cerca de 15 minutos, e as esperas mais longas caíram de mais de uma hora para cerca de 45 minutos.
* A UI CircleCI está começando a alcançar, mas ainda está atrás. Fluxos de trabalho e trabalhos podem já ter sido executados, ou podem estar em execução, mesmo se a UI mostra-los como não iniciado ou não mostrá-los em tudo.
* Pipelines estão sendo processados mais rápido, mas novos pipelines ainda estão atrasados.
Ainda em curso
* Alguns fluxos de trabalho e trabalhos ainda estão falhando.
* Por favor, evite retriggering fluxos de trabalho que ainda não aparecem na UI, pois isso pode criar duplicatas.
* Dados de cobrança de uso na página de Uso do Projeto está obsoleto.
Próxima atualização
Nós forneceremos outra atualização até 19:30 UTC.
identified
Desde nossa última atualização, os trabalhos estão começando mais rápido: a maioria agora está começando em cerca de 6 minutos, para baixo de cerca de 8 minutos. A UI CircleCI está a recuperar, mas ainda está uma hora atrasada. Novas condutas estão a ser processadas à medida que chegam.
Tarefas já podem ter sido executadas mesmo que a UI ainda não as mostre, então por favor evite retriggering workflows que não aparecem na UI.
Nós forneceremos outra atualização até 20:00 UTC.
identified
Os trabalhos estão começando mais rápido e menos estão falhando: a maioria dos trabalhos estão começando agora em cerca de 4 minutos, para baixo de cerca de 6 minutos, e as esperas mais longas caíram de cerca de 30 minutos para cerca de 20 minutos.
Os tubos do incidente estão agora a ser trabalhados.
A UI CircleCI ainda está por trás, e algumas atualizações mais antigas podem levar mais tempo para aparecer. Tarefas já podem ter sido executadas mesmo que a UI ainda não as mostre, então por favor evite retriggering workflows que não aparecem na UI.
Nós forneceremos outra atualização até 20:30 UTC.
identified
Desde cerca de 20:48 UTC, novos fluxos de trabalho e trabalhos não estão começando. Nós pausamos temporariamente o início de um novo trabalho para que nossos sistemas possam recuperar o trabalho já em andamento, incluindo atualizações atrasadas para a interface CircleCI e API. Atualizações mais antigas agora estão aparecendo na UI e API conforme este backlog é liberado. Novos gasodutos ainda estão sendo aceitos e em fila de espera
Por favor, evite retriggering pipelines ou fluxos de trabalho durante este tempo, pois isso pode criar duplicatas uma vez que o trabalho retoma.
Nós forneceremos outra atualização até 22:00 UTC.
identified
Desde a nossa última atualização, a maioria dos pipelines que foram atrasados mais cedo no incidente agora foram processados, e seus fluxos de trabalho estão em fila para começar. Novos fluxos de trabalho e trabalhos permanecem em pausa enquanto nos preparamos para retomar o trabalho com segurança. Atualizações tardias continuam aparecendo na UI e API do CircleCI.
Por favor, continue a evitar retriggering pipelines ou fluxos de trabalho, pois isso pode criar duplicatas uma vez que o trabalho retoma.
Nós forneceremos outra atualização até 22:30 UTC.
identified
Desde nossa última atualização, começamos a retomar gradualmente o trabalho, e alguns fluxos de trabalho em fila de espera e trabalhos estão começando novamente. A maioria dos trabalhos em fila de espera ainda está esperando, e trabalhos que começam podem ter esperado mais de uma hora. Estamos aumentando a taxa cuidadosamente para evitar sobrecarregar nossos sistemas. Atualizações tardias continuam aparecendo na UI e API do CircleCI.
Por favor, continue a evitar retriggering pipelines ou fluxos de trabalho, uma vez que isso pode criar duplicatas como o trabalho em fila retoma.
Nós forneceremos outra atualização até 23:00 UTC.
identified
Um grande número de workflows e trabalhos em filas de espera já começaram, e a UI e API do CircleCI têm alcançado e estão mostrando atualizações normalmente com poucos atrasos. Continuamos a trabalhar através do restante trabalho em fila. Os trabalhos da fila podem ter esperado cerca de uma hora ou mais para começar, e alguns trabalhos Linux estão esperando até cerca de 10 minutos para a capacidade.
Por favor, continue a evitar a repetição enquanto o trabalho em fila continua a processar.
Nós forneceremos outra atualização até 23:30 UTC.
identified
Ainda estamos trabalhando através de um significativo backlog de fluxos de trabalho em fila de espera e trabalhos. Os tempos de espera estão a melhorar, mas permanecem mais do que o normal e alguns empregos esperaram mais de uma hora. A interface CircleCI e API permanecem atualizadas. Por favor, evite retriggering pipelines ou fluxos de trabalho enquanto o backlog limpa, pois isso pode criar duplicatas. Nós forneceremos outra atualização até 00:00 UTC.
identified
Desde nossa última atualização, o backlog de fluxos de trabalho e trabalhos em filas de espera foi limpo, a partir de cerca de 23:47 UTC. Fluxos de trabalho e trabalhos estão começando em segundos, e a interface CircleCI e API estão atualizadas. Estamos monitorando nossos sistemas de perto para garantir que eles permaneçam estáveis. Nós forneceremos outra atualização até 00:30 UTC.
identified
Fluxos de trabalho e trabalhos continuaram a começar normalmente, em segundos, e a UI CircleCI e API permanecem atualizadas. As notificações de Slack e email atrasadas mais cedo no incidente ainda estão sendo entregues.
Dados de carga de uso na página de Uso do Projeto estão obsoletos.
Continuamos a monitorar nossos sistemas de perto e forneceremos outra atualização até 01:15 UTC.
monitoring
Fluxos de trabalho e trabalhos estão começando e rodando normalmente, e a interface CircleCI e API estão atualizadas. Continuamos a monitorizar de perto os nossos sistemas para garantir que se mantêm estáveis.
Nós forneceremos outra atualização até 02:00 UTC.
resolved
Entre 11:15 UTC e 23:47 UTC em 9 de outubro, os clientes experimentaram atrasos e falhas em pipelines, fluxos de trabalho e trabalhos, juntamente com atrasos na UI CircleCI, API e notificações.
De 11:15 a cerca de 13:00 UTC, pipelines foram criados, mas não processados, e notificações de saída webhooks e Slack e e-mail não foram enviados. Das 13:00 às 14:40 UTC, fluxos de trabalho e trabalhos começaram com atrasos enquanto trabalhávamos no backlog.
De cerca de 15:15 a 20:48 UTC, fluxos de trabalho e trabalhos começaram com atrasos crescentes, de até cerca de uma hora, e a UI CircleCI e API ficaram para trás até cerca de 2 horas. Durante este tempo, alguns trabalhos não conseguiram iniciar e alguns fluxos de trabalho em andamento falharam.
De 20:48 a cerca de 22:10 UTC, pausamos temporariamente o início de novos fluxos de trabalho e trabalhos para que nossos sistemas pudessem se recuperar. Novos gasodutos foram aceitos e em fila durante este tempo. De cerca de 22:10 a 23:47 UTC, fluxos de trabalho em fila e trabalhos retomados e foram processados. Alguns deles tinham esperado até cerca de 2 horas.
O problema foi resolvido e toda a funcionalidade afetada voltou ao normal. Dados de cobrança de uso na página de Uso do Projeto ainda não estão atualizados e serão atualizados assim que nossos dados forem preenchidos. Clientes cujos trabalhos falharam durante esta janela podem repetir trabalhos afetados. Agradecemos sua paciência enquanto nossos engenheiros trabalharam na implementação de uma correção.
postmortem
# # Resumo
Entre 11:15 UTC e 23:47 UTC em 9 de outubro, clientes da CircleCI experimentaram atrasos de horas e falhas em pipelines, fluxos de trabalho e trabalhos, juntamente com atrasos na UI CircleCI, API e notificações.
* Das 11:15 às 13:00 UTC, os pipelines foram criados, mas não processados, e as notificações de e-mail foram enviadas.
* Das 13:00 às 14:40 UTC, fluxos de trabalho e trabalhos começaram com atrasos enquanto trabalhávamos no backlog.
* De 15:15 a 20:48 UTC, fluxos de trabalho e trabalhos começaram com atrasos crescentes, de até cerca de uma hora, e a UI CircleCI e API ficaram para trás por cerca de 2 horas. Durante este tempo, alguns trabalhos não conseguiram iniciar e alguns fluxos de trabalho em andamento falharam.
* De 20:48 a 22:10 UTC, nós pausamos temporariamente iniciar novos fluxos de trabalho e trabalhos para que nossos sistemas pudessem recuperar. Novos gasodutos foram aceitos e em fila durante este tempo.
* De 22:10 a 23:47 UTC, fluxos de trabalho em fila e trabalhos retomados e foram processados com sucesso. Alguns deles tinham esperado até cerca de 2 horas.
* Em 23:47, o incidente foi atenuado.
A página de status deste incidente pode ser encontrada em [9 de outubro - Atraso nos dados que aparecem na UI e API](https://status.circleci.com/incidents/6cfhhlr4rmm0). Os clientes tiveram um incidente semelhante no início da semana em [6 de outubro - Atrasos em pipelines, fluxos de trabalho, dados de IU e notificações](https://status.circleci.com/incidents/z4hbq8h49j8c).
Vários serviços do CircleCI usam o Temporal apoiado por Postgres como um mecanismo confiável de fila de espera, e ambos os incidentes tiveram a mesma causa: a taxa de escrita para a instância Postgres do Temporal foi mais rápida do que o registro de transações do Postgres poderia arquivar esses escritos. Em ambos os casos, isso causou atrasos de várias horas no processamento de pipelines e notificações de status.
Nós avaliamos várias mitigação, então pausamos o início do novo fluxo de trabalho para que o sistema pudesse se recuperar com segurança e aumentar gradualmente. Em seguida, aceleramos o trabalho até que nossos sistemas voltaram ao normal.
Para resolver permanentemente o gargalo, dividimos o trabalho em várias instâncias Temporais, cada uma com seu próprio banco de dados independente e grupos de trabalhadores, e carregamos o equilíbrio entre eles. Já tínhamos programado trabalhos de infra-estruturas a partir da semana de 12 de Outubro, que teriam eliminado este estrangulamento exacto e evitado estes incidentes. Então, começando 19:11 em 9 de outubro, nossa equipe de engenharia implementou, testou e lançou uma versão mais simples dessas mudanças em poucas horas. Adicionamos novos alertas e afinamos as bases de dados subjacentes para melhor desempenho sob alta carga.
Os clientes cujos trabalhos falharam durante esta janela podem repeti- los.
# # Fundo
Para executar trabalhos de clientes, o CircleCI executa uma série de passos: aceitamos oleodutos de clientes; atribuímos empregos para esses oleodutos aos trabalhadores; entregamos atualizações de status para esses oleodutos e empregos; e cobramos clientes pelos créditos que esses empregos consomem. Cada uma dessas etapas é implementada por um serviço independente, com filas confiáveis no meio.
Historicamente implementamos essas filas confiáveis com o RabbitMQ em cima de armazenamento durável, com filas exponenciais de backoff e de letras mortas para confiabilidade. Ao longo do ano passado, reimplementámos cada vez mais as nossas filas fiáveis em [Temporal](https://temporal.io/), o que proporciona garantias de durabilidade e fiabilidade muito melhores ao longo de um modelo de programação mais simples e mais poderoso. Nosso serviço build \(que transforma uma configuração pipeline em um plano executável\), nosso serviço de orquestrador de fluxo de trabalho \(que distribui tarefas para os trabalhadores\), nosso serviço de notificação \(que entrega atualizações de status\), e nosso serviço de carregamento \(que cobra clientes para créditos\) todos agora usam Temporal.
Temporal armazena o estado para seus fluxos de trabalho e atividades \(chamado de "história"\) em um banco de dados, e este é o único componente em uma instância Temporal que é síncrona e estatal. Como consequência, a capacidade de uma instância temporal de aceitar e executar fluxos de trabalho depende da taxa de escrita de seu banco de dados de apoio. Nós também configuramos Temporal para excluir fluxos de trabalho e atividades completas de seu histórico 3 dias após o seu término.
No momento desse incidente, usamos uma única instância Temporal agrupada apoiada por uma instância RDS Multi-AZ Postgres para todas essas filas confiáveis. Enquanto uma instância RDS Multi-AZ é resistente a falhas de zona, ele mantém a consistência do banco de dados através de um único write-ahead-log \(WAL\). Na época, tínhamos configurado nossa instância Postgres para armazenar seu WAL em um Volume de Log dedicado \(DLV\) para que as escritas de log não competem com as escritas de dados. O banco de dados arquiva o log continuamente para o armazenamento de backup, e só pode reutilizar o espaço no volume após o log ter sido arquivado. Se o banco de dados escreve logs mais rápido do que ele arquivos, o volume enche e Postgres não tem espaço para escrever seu registro WAL. Em seguida, o banco de dados para de aceitar mensagens recebidas e vai inteiramente somente leitura. Um RDS DLV está limitado a 1 TB de armazenamento e 3000 IOPS e por AWS esses limites são codificados e não podem ser aumentados.
# # O Que Aconteceu
\(Todas as vezes UTC\)
Um dos fatores contribuintes para o incidente de 6 de outubro foi que estávamos processando uma alta taxa de deleções de histórico temporal ao mesmo tempo que o trabalho que está chegando, que, por sua vez, exercer pressão sobre o banco de dados de apoio. Para resolver o incidente de 6 de outubro, mudamos as configurações de limpeza nas maiores tabelas do Temporal e transferimos o registro de transação de volta para seu volume dedicado. Essas alterações eliminaram a principal fonte de registro de transação escreve, mas não consideraram o registro adicional escreve de deleções agendadas. Como configuramos o Temporal para excluir fluxos de trabalho e atividades completas de seu histórico 3 dias após o seu término, o histórico de 6 de outubro foi programado para ser excluído em 9 de outubro.
A partir das 08:00 em 9 de outubro, o Temporal começou a processar as deleções programadas, e como consequência, o espaço livre no Postgres DLV começou a cair precipitadamente, de 0,8 TB às 08:00 para 0,1 TB às 10:10. A nossa monitorização alertou às 10:28 e declaramos um incidente às 10:31. Enquanto a nossa equipa de infra-estruturas investigava, às 11:15 o DLV ficou sem espaço e a instância dos Postgres foi apenas para leitura. Isto parou todo o processamento temporal em suas faixas.
Às 11:42, reiniciamos o Postgres para mover o registro WAL do DLV para o volume de dados e usar o espaço em disco de reposição e IOPS lá. Esta manobra tinha atenuado o incidente em 6 de outubro, e sabíamos que levaria cerca de 60 minutos.
Enquanto o banco de dados estava reiniciando, começamos a implementar várias técnicas de load-shedding a montante do Temporal:
* Começamos a investigar se deveríamos perder cargas de trabalho para manter o resto em movimento, mas finalmente decidimos que isso não daria valor.
* Às 12:29, assinalámos as atualizações de cobrança de crédito, que representavam 12% das atividades Temporais. Isso deixou a página de Uso do Pipeline com dados de carregamento obsoletos, até que nós iria enchê-lo, mas não iria perder dados ou impedir pipelines de correr.
Às 12:59, o banco de dados estava de volta e começou a processar trabalhos que tinham fila desde as 11:15 e às 14:40, esse atraso tinha sido liberado e os trabalhos estavam começando a tempo. No entanto, em 15:15, os atrasos retornaram como a limpeza de roteamento do banco de dados tinha caído muito atrás nas tabelas usos temporais para rastrear fila e trabalho agendado. Essas mesas normalmente mantêm dezenas de milhares de fileiras apagadas à espera de limpeza, mas no final da tarde, elas seguravam dezenas de milhões de fileiras. Cada operação temporal teve que ler além dessas linhas, então o banco de dados gastou muito mais tempo de processamento em cada um e Temporal correu mais devagar. Isto resultou em os clientes continuarem a ver atrasos de hora em iniciar gasodutos e em atualizações de status.
Durante as próximas horas, tentamos várias mitigação, incluindo:
* Manipulando valores de configuração temporal para reduzir a pressão do banco de dados. Isto teve um efeito mínimo.
* Executar trabalhos manuais de vácuo para limpar fileiras mortas em Postgres. Isso acabou competindo pela CPU com consultas próprias, e foi finalmente contraproducente. Cancelámo-los às 17h45 para aliviar a pressão na carga do banco de dados.
* Começamos a tentar mover todos os usecases de notificação para uma instância temporal separada. Isso representou 18% das atividades temporais. Terminamos com sucesso as notificações em movimento às 17:07.
* Às 17:16, implementamos com sucesso uma otimização em nossa representação do estado do gasoduto, o que o reduziu em 5%. Isso, por sua vez, reduziu o tamanho do banco de dados escreve e, portanto, pressão de dados sobre o registro WAL Postgres.
Nenhum deles mitigou totalmente a questão.
Por volta de 20:48, percebemos que Postgres estava agora batendo na CPU do banco de dados e não estava mais bloqueado em log escreve. Percebemos ainda que os nossos sistemas a montante estavam a submeter novos trabalhos e também a tentar novamente trabalhos que tinham sido submetidos e falhado anteriormente. Reconhecendo que estávamos em uma tempestade de repetição clássica, nós pausamos todo o trabalho de entrada e repetição e deixá-lo fila acima, a fim de permitir que o banco de dados para completar totalmente o trabalho em processo. Em seguida, lentamente aceleramos o trabalho em fila de espera das 22:07 para manter o banco de dados em uma carga sustentável.
Isso foi totalmente sucedido por 23:47 quando todo o trabalho em fila de espera tinha começado, e nós encerramos o incidente às 02:08 em 10 de outubro.
# # Prevenção futura e melhoria do processo
Múltiplas instâncias temporais
Em paralelo com a mitigação e resolução de incidentes, a partir de 19:11 em 9 de outubro, também começamos a levantar várias instâncias temporais estilhaçadas e implementar a capacidade de equilibrar o trabalho entre elas.
Cada uma das múltiplas instâncias temporais mantém seu próprio banco de dados independente e clusters de trabalhadores, e assim é isolado dos outros. Como item de ação postmortem do incidente de 6 de outubro, já tínhamos programado trabalho de infraestrutura que teria removido o gargalo de uma única instância temporal e banco de dados Postgres, a partir de 12 de outubro e esperando levar 2 semanas. Em 9 de outubro, percebemos que este trabalho simplesmente não podia esperar, então nossa equipe de engenharia implementou, testou e lançou uma versão mais simples das mudanças planejadas em poucas horas.
Estas alterações completaram-se com sucesso às 01:45 de Outubro.
**Além disso, estamos mudando como armazenamos e monitoramos os registros de transações.** Nosso banco de dados Temporal não usa mais o volume de log de tamanho fixo. Estamos adicionando alertas sobre quão longe o arquivo de log cai atrás e quão rápido o banco de dados escreve logs, para que possamos agir horas antes do que fizemos em 9 de outubro.
** Também estamos revisitando o cronograma de eliminação do Temporal.** A exclusão temporal terminou o trabalho alguns dias depois de ser executado, então um dia movimentado retorna como carga de banco de dados no final da semana. Estamos mudando quando e quão rapidamente essas eliminações são executadas.
** Estamos mudando como nossos sistemas retentam quando Temporal é lento.** Em 9 de outubro, nossos sistemas tentaram novamente o trabalho fracassado contra o Temporal e adicionaram à sua carga. Como cometemos após o incidente de 6 de outubro, estamos mudando nossos sistemas para esperar que o Temporal se recupere para que o trabalho não seja abandonado.
# # Conclusão
A experiência do cliente é nossa principal prioridade, e nos comprometemos a melhorar continuamente a confiabilidade de nossos sistemas para corresponder à confiança que nossos clientes depositam em nós. Agradecemos aos nossos clientes pela sua paciência enquanto a nossa equipa trabalhou para resolver estes incidentes.
Por favor, contacte a nossa equipa de apoio com quaisquer perguntas ou preocupações.
Traduzido automaticamente da atualização oficial do incidente.
Tempos de espera elevados para trabalhos de máquinas
Início 8 Here 2026 da 13:00 UTC · 3h 35m
IssuesMinor incident
Componentes afetados
Machine Jobs
identified
Os clientes podem estar experimentando tempos de espera elevados para trabalhos de máquina. Estamos a trabalhar para resolver isto.
identified
Os clientes que usam trabalhos de máquinas Linux estão experimentando tempos de espera elevados, com média de cerca de 11 minutos, com as esperas mais longas superiores a 30 minutos nas classes média, bram.medium e arm.large recursos. Os nossos engenheiros identificaram o problema e estão a trabalhar numa solução. Nós forneceremos outra atualização até 14:00 UTC.
identified
Os clientes que usam trabalhos de máquinas Linux estão experimentando tempos de espera elevados, com média de cerca de 40 minutos, com as esperas mais longas superiores a 50 minutos. A maioria das classes de recursos de máquina Linux são afetadas, incluindo média, grande, xlarge, 2xlarge e seus equivalentes de Braço. Os nossos engenheiros identificaram o problema e estão a trabalhar numa solução. Nós forneceremos outra atualização até 14:30 UTC.
identified
Clientes usando trabalhos de máquina Linux e Docker remoto estão experimentando tempos de espera elevados. Os tempos de espera começaram a diminuir e agora em média cerca de 20 minutos, com as esperas mais longas superiores a 40 minutos em algumas classes de recursos. Os nossos engenheiros identificaram o problema e estão a trabalhar numa solução. Nós forneceremos outra atualização até 15:00 UTC.
identified
Uma correção foi implantada e os tempos de espera estão diminuindo, mas os clientes usando trabalhos de máquina Linux e Remote Docker ainda estão passando por atrasos. O tempo de espera atualmente é em média de 11 minutos, com as esperas mais longas superiores a 35 minutos em algumas classes de recursos. Estamos a trabalhar para aumentar a capacidade o mais rapidamente possível. Nós forneceremos outra atualização até 15:30 UTC.
identified
Os tempos de espera continuam a diminuir, mas os clientes que usam trabalhos de máquina Linux e Docker remoto ainda estão passando por atrasos. Tempos de espera atualmente em média cerca de 6 minutos. As esperas mais longas, até cerca de 20 minutos, estão no 2xlarge, braço.2xlarge e gpu.nvidia. pequenas classes de recursos. Estamos a trabalhar para aumentar a capacidade o mais rapidamente possível. Nós forneceremos outra atualização até 16:00 UTC.
identified
Os tempos de espera continuam a diminuir, mas os clientes que usam trabalhos de máquina Linux e Docker remoto ainda estão passando por atrasos. Tempos de espera atualmente em média cerca de 90 segundos, com as esperas mais longas até cerca de 6 minutos em algumas classes de recursos. Estamos a trabalhar para aumentar a capacidade o mais rapidamente possível. Vamos fornecer outra atualização até 16:30 UTC.
monitoring
Tempos de espera para os clientes usando trabalhos de máquina Linux e Docker remoto retornaram ao normal. Estamos monitorando para confirmar que os tempos de espera permanecem estáveis enquanto continuamos a adicionar capacidade. Vamos fornecer outra atualização até 16:30 UTC.
resolved
Entre 12:40 UTC e 16:00 UTC em 8 de outubro, os clientes usando trabalhos de máquina Linux e Docker remoto experimentaram tempos de espera elevados. O problema foi resolvido e os tempos de espera voltaram ao normal. Agradecemos a sua paciência, enquanto nossa equipe trabalhou na implementação de uma correção.
postmortem
# # Resumo
Desde 1o de outubro, os clientes da CircleCI experimentaram vários incidentes que causaram atrasos e falhas na execução do pipeline do cliente. Existem duas causas \(não relacionadas\), ambas as quais a equipe de engenharia CircleCI está mitigando ativamente:
* Capacidade de computação em nuvem disponível
* Infraestrutura Interna
# # Capacidade disponível de computação em nuvem
* **Problema**: A demanda por instâncias de nuvem de alto desempenho está aumentando extremamente rapidamente em todo o setor, o que coloca pressão sobre os tipos de instância de provedor de nuvem que usamos para executar trabalhos de clientes.
* **Incidentes**:
* (https://status.circleci.com/incidentes/jn756xtsy4xg)
* [Tempos de espera de tarefas aumentados para Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd)
* [O nível elevado de infra-estruturas falha nos empregos dos clientes](https://status.circleci.com/incidents/0z31ldjd8m5v)
* [Atraso em iniciar tarefas de trabalho de máquina] (https://status.circleci.com/incidents/tj6wdnfjwr64)
* [Atrasos começando Gen 2 Docker Jobs] (https://status.circleci.com/incidents/22mrv46g6n7g)
* **Mitigações e Resoluções**:
* Estamos expandindo nosso conjunto de regiões de computação em nuvem para incluir regiões adicionais com instâncias de alto desempenho disponíveis.
* Também estamos trabalhando para garantir capacidade adicional garantida de nossos parceiros de computação em nuvem em nossas regiões existentes.
* Estamos expandindo ainda mais o conjunto de tipos de instância que podemos oferecer aos clientes.
* Publicaremos um relatório detalhado sobre esses incidentes em 9 de outubro de 2026.
# # Infraestrutura Interna
* **Problema**: Nós atribuímos fluxos de trabalho de clientes sobre vários provedores de computação através de um serviço de orquestração de fluxo de trabalho. Este serviço é atualmente fechado pelo rendimento de escrita de um único banco de dados.
* **Incidentes:**
* [Atrasos em pipelines, fluxos de trabalho, dados de UI e notificações](https://status.circleci.com/incidents/z4hbq8h49j8c)
* [Manutenção de infraestrutura de emergência](https://status.circleci.com/incidents/g60yc9bvkmx)
* **Mitigações e Resoluções**:
* Em 23 de outubro de 2026, planejamos implementar várias instâncias redundantes de serviços de orquestração de fluxo de trabalho, cada uma com seu próprio banco de dados, o que nos permitirá dividir a carga de orquestração entre eles.
# # Nosso compromisso
Para evitar dúvidas,
* Estes incidentes particulares não estão relacionados com interrupções contínuas em Github
* Atualmente não estamos migrando nossa infraestrutura ou serviços
* Nós não estamos atualmente sob ataque cibernético
A experiência do cliente é nossa principal prioridade, e nos comprometemos a melhorar continuamente a confiabilidade de nossos sistemas para corresponder à confiança que nossos clientes depositam em nós. Agradecemos aos nossos clientes pela sua paciência, enquanto nossa equipe trabalhou para resolver esses incidentes e trabalha para evitar futuros incidentes.
Por favor, contacte a nossa equipa de apoio com quaisquer perguntas ou preocupações.
Traduzido automaticamente da atualização oficial do incidente.
Aumento dos tempos de espera da tarefa para o Docker Gen2
Início 7 Here 2026 da 18:54 UTC · 1h 11m
IssuesMinor incident
Componentes afetados
Docker Jobs
identified
Há um maior tempo de espera para trabalhos em Docker Gen2.
identified
Nota: os atrasos serão mais perceptíveis para as pessoas em execução no Docker `xlarge` e acima.
monitoring
Ainda estamos vendo picos nos tempos de espera da tarefa, mas em média os tempos de espera estão olhando melhor para todos Docker Gen2.
resolved
Este incidente foi resolvido.
postmortem
## **Resumo #
Entre 1 de outubro e 8 de outubro de 2026, os clientes da CircleCI experimentaram cinco incidentes separados em que os trabalhos esperaram mais do que o normal para começar, ou não conseguiram começar. Três dos incidentes foram impulsionados pela disponibilidade de instância limitada do nosso provedor de nuvem. Uma foi causada por um problema de configuração em nossa infraestrutura de agendamento, e uma por limites de memória em um serviço interno, que levantamos durante o incidente.
* 1 de outubro, 07:57 a 10:24 UTC:** Os trabalhos do Docker Gen 2 esperaram até 30 minutos para começar. Um problema de configuração impediu os servidores de agendamento Gen 2 de usar seus discos locais de alto desempenho. Durante uma explosão no tráfego, os discos de retorno saturados e colocação de trabalho diminuiu.
* ** 7 de outubro, 13:27 - 14:06 UTC:** Empregos de máquinas esperaram mais do que o normal porque não conseguimos adquirir máquinas virtuais suficientes do nosso provedor de nuvem.
* ** 7 de outubro, 14:24 a 15:21 UTC:** Alguns trabalhos falharam com um erro de infraestrutura, e os fluxos de trabalho foram atrasados. O serviço que dá a cada trabalho sua configuração na inicialização ficou sem memória e reiniciado.
* ** 7 de outubro, 18:49 a 20:05 UTC:** Os trabalhos do Docker Gen 2 esperaram mais do que o normal porque não conseguimos obter instâncias suficientes do nosso provedor de nuvem.
* ** 8 de outubro, 12:48 - 16:00 UTC:** Trabalhos de máquinas Linux e trabalhos remotos do Docker esperaram até 50 minutos para começar. Nosso provedor de nuvem não tinha o suficiente do tipo de instância que solicitamos, e um defeito na lógica que escolhe um tipo de instância diferente nos impediu de usar alternativas.
Os empregos que esperavam durante estes incidentes foram atrasados, não perdidos. Clientes cujos trabalhos falharam com um erro de infraestrutura durante o incidente de 7 de outubro de 14:24 a 15:21 UTC pode repeti-los.
As páginas de status originais podem ser encontradas abaixo:
* [1 de Outubro - Atrasos iniciados Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g)
* [7 de outubro - Atraso no início das tarefas de trabalho de máquina] (https://status.circleci.com/incidents/tj6wdnfjwr64)
* [7 de Outubro - Nível elevado de falhas de infra-estruturas nos empregos dos clientes](https://status.circleci.com/incidents/0z31ldjd8m5v)
* [7 de outubro - Aumento dos tempos de espera para Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd)
* [8 de Outubro - Tempos de espera elevados para trabalhos de máquinas](https://status.circleci.com/incidents/jn756xtsy4xg)
Antecedentes
Todos os trabalhos que funcionam no CircleCI precisam de computação. De onde esse cálculo vem depende do executor.
Os trabalhos de Docker são executados em clusters de servidores que agendam trabalho em uma frota de instâncias. O programador é o software nos servidores que decidem qual instância executa cada trabalho. Os trabalhos de Docker Gen 2 funcionaram em um desses clusters no momento do incidente de 1 de outubro. Os empregos de Docker Gen 1 estão espalhados por vários clusters.
Trabalhos de máquinas, incluindo trabalhos remotos Docker, obter uma máquina virtual dedicada. Um trabalho remoto do Docker é tratado como um trabalho de máquina Linux desde submissão até provisionamento. O nosso serviço de fornecimento de máquinas requer cada máquina do nosso fornecedor de nuvem em uma das duas regiões que normalmente usamos para trabalhos de máquinas. Quando o provedor não pode fornecer o tipo de instância que solicitamos, o serviço recua: solicita um tipo de instância diferente, ou uma região diferente, de uma lista que mantemos. Um trabalho espera até que uma máquina esteja disponível.
Quando qualquer trabalho começa, ele pede um serviço de configuração de trabalho para sua configuração. Esse serviço funciona como um conjunto de pods, que são pequenas cópias do mesmo programa. Se muitos pods pararem, os pods restantes carregam mais carga, e os trabalhos não podem começar até que o serviço recupere.
Esses caminhos dependem de três tipos de capacidade: o rendimento de nossos sistemas de agendamento, o fornecimento de instâncias de nosso provedor de nuvem, e a memória e número de cópias dos serviços que iniciam trabalhos. Uma falha em qualquer um deles faz trabalhos esperar ou falhar.
* O que aconteceu *
\(Todas as vezes UTC\)
# # # Outubro 1: Docker Gen 2 trabalhos atrasados até 30 minutos #
Às 07:44, a atividade do disco nos servidores que agendam os trabalhos do Docker Gen 2 subiu para 90% da capacidade e ficou lá. Às 07:57, o número de empregos do Docker à espera para começar a crescer, e os tempos de espera aumentaram com ele. Um alerta automatizado chamou o engenheiro de plantão às 08:08. Declaramos um incidente às 08:42.
Às 08:43, os engenheiros identificaram alta latência do disco nos servidores de agendamento. Eles primeiro acreditavam que os discos eram muito lentos para a carga, então eles prepararam uma mudança para um tipo de disco mais rápido. Às 09:01, a equipe concordou em dois workstreams: mover os servidores para discos mais rápidos, e adicionar um segundo cluster Gen 2 para que os trabalhos fossem divididos em dois clusters.
Às 09:41, os engenheiros encontraram a causa raiz. Cada servidor de agendamento tem discos rápidos anexados diretamente a ele, e o escalonador é feito para manter seus dados de trabalho lá. Esses servidores são executados em uma imagem de sistema operacional enrijecida por segurança, e nessa imagem os discos rápidos não estavam sendo usados. O programador escreveu seus dados para discos mais lentos ligados à rede. O script que configura os discos rápidos falhou sem um erro, e uma lacuna no registro nesses servidores escondeu a falha. O tráfego do GN 2 também se tornou cada vez mais intenso. Os discos mais lentos saturaram durante essas explosões, e o programador caiu para trás.
Os tempos de espera chegaram às 09:54, quando os trabalhos na classe de recursos médios Gen 2 esperaram até 30 minutos. Às 09:55, os engenheiros aplicaram uma correção que configurou os discos rápidos corretamente. Às 10:11, o agendador começou a colocar trabalhos mais rápido, o que confirmou que os servidores poderiam acompanhar novos trabalhos. Tempos de espera para Gen 2 média caiu para 13 minutos em 10:14, 7 minutos em 10:17, e 1 minuto 30 segundos em 10:20. Mudamos a página de status para monitoramento às 10:24 e resolvemos o incidente às 10:45.
Às 11:20, o segundo cluster Gen 2 começou a executar trabalhos.
7 de Outubro, 13:27 a 14:06: Tempos elevados de espera para trabalhos de máquinas
Declaramos um incidente às 13:27 depois de vermos filas e esperas elevadas. Nós afixamos na página de status às 13:31. Às 13:31, os engenheiros viram que estávamos lutando para adquirir máquinas virtuais para trabalhos de máquinas, e que o número de trabalhos esperando para começar era alto principalmente para trabalhos de máquinas. Às 13:34, os tempos de espera foram elevados entre os executores.
Às 13:48, os tempos de espera começaram a se recuperar à medida que mais máquinas ficavam disponíveis, e resolvemos o incidente às 14:06.
## # ** 7 de outubro, 14:24 a 15:21: falhas de trabalho e atrasos no fluxo de trabalho**
Pouco depois que o incidente anterior foi marcado como resolvido, declaramos um novo incidente às 14:24 devido a uma queda acentuada no número de trabalhos submetidos aos nossos sistemas de execução. Às 14:26, os engenheiros viram que os pods do serviço de configuração de trabalho estavam reiniciando. Pods que reiniciam deixam menos cópias do serviço para responder aos pedidos, e trabalhos que não puderam recuperar sua configuração após tentativas repetidas falharam com um erro de infraestrutura. Fluxos de trabalho que já estavam em execução esperaram por atualizações de trabalhos que não tinham começado.
Às 14:35, os engenheiros aumentaram a quantidade de memória disponível para as vagens e aumentaram o número de vagens, o que deu ao serviço mais cópias para compartilhar a carga. Nós também aumentamos a quantidade de mensagens de trabalho disponíveis de memória começou a recuperar, e o número de mensagens fluindo através do nosso sistema de fluxo de trabalho retornou aos níveis normais. Às 14:44, mudamos a página de status para monitoramento.
Pods no serviço de configuração de tarefas atingiram seus limites de memória e reiniciaram. Aumentamos a alocação de memória e a contagem de cápsulas, e o serviço recuperado. Aos 15:13, nós aumentamos o número de casos em nossos clusters de Docker Gen 2 para que pudéssemos trabalhar através do atraso de empregos de espera rapidamente. Resolvemos o incidente às 15h21.
## ** 7 de Outubro, 18:49 a 20:05: Tempos de espera elevados para trabalhos do Docker Gen 2**
Declaramos um novo incidente às 18:49, depois de o Docker Gen 2 ter aparecido. Às 18:51, os engenheiros confirmaram que uma escassez de instâncias disponíveis nos impediu de adquirir bastante delas, o que aumentou os tempos de espera. Os tempos de espera diferiram pelo tamanho da classe de recursos.
Aos 19:52, os tempos médios de espera eram inferiores a uma hora antes, à medida que mais capacidade se tornava disponível, embora os picos breves continuassem, e movemos a página de status para monitoramento. Resolvemos o incidente às 20h05.
## # ** 8 de Outubro: a máquina Linux e os trabalhos remotos do Docker esperam até 50 minutos**
Declaramos um incidente às 12:48, depois de ver um grande número de trabalhos esperando para começar e longos tempos de espera para trabalhos de máquina e Docker remoto. Às 12:49, os engenheiros viram que nosso provedor de nuvem não podia fornecer instâncias suficientes. Os atrasos continuaram a subir enquanto investigamos.
Aos 13:13, começamos a examinar a lógica que escolhe um tipo de instância ou região diferente quando nossa primeira escolha não está disponível. Às 13:24, suspeitávamos que um defeito nessa lógica estava nos impedindo de usar outros tipos de instância em nossa região primária, então desativamos nossa região de retrocesso e confirmamos a causa do defeito. Os engenheiros começaram a trabalhar em uma correção e a implantaram às 14:49. O serviço começou a solicitar outros tipos de instância e começou máquinas em grande número. Às 14:58, a fila de empregos à espera de uma máquina caiu constantemente. Tempos médios de espera entre as classes de recursos continuaram a cair durante a próxima hora enquanto trabalhávamos através do backlog de trabalhos de espera.
Às 16:00, a fila de trabalhos à espera de uma máquina limpa e o número de trabalhos de espera voltaram ao normal. Mudamos a página de status para monitoramento às 16:09 e resolvemos o incidente às 16:35.
** ** Prevenção do Futuro e Melhoria do Processo **
Estamos tomando as seguintes medidas para fortalecer a resiliência dos tempos de início do trabalho, incluindo diversificação da oferta, lógica de retrocesso e detecção anterior.
** Estamos expandindo nossas regiões de computação.** Nos incidentes de 7 de outubro e 8 de outubro, nosso provedor de nuvem não poderia fornecer instâncias suficientes nas regiões que usamos. Estamos adicionando novas regiões à nossa lógica de retrocesso para lidar com picos de demanda que ultrapassam nossas regiões preferidas.
** Estamos fixando a lógica que escolhe um tipo de instância diferente.** Em 8 de outubro, um defeito impediu o serviço de fornecimento da máquina de usar outros tipos de instância na mesma região. Implantamos uma correção durante o incidente e agora estamos revisando e refatorando essa lógica como um todo, com testes, de modo que uma escassez de um tipo de instância se move para outro.
**Estamos expandindo os tipos de instância que oferecemos e garantindo capacidade adicional.** Estamos trabalhando com nosso provedor de nuvem para reservar capacidade adicional em nossas regiões existentes, e estamos adicionando tipos de instância que os trabalhos podem ser executados. A demanda da indústria por computação de alto desempenho está crescendo. Estamos diversificando onde e como nós fonte de capacidade para que nossos clientes são isolados da variação da oferta.
** Nós adicionamos um segundo cluster de Docker Gen 2 para que as explosões de tráfego sejam distribuídas em dois clusters.** Também estamos adicionando alertas sobre a saturação do disco do servidor de agendamento e sobre a rapidez com que o programador coloca trabalhos, e um alerta que dispara quando um servidor começa sem seus discos rápidos em uso. Fizemos o script de configuração de disco falhar com um erro, e restauramos o envio de log desses servidores para que um problema semelhante seja visível mais cedo.
A experiência do cliente é nossa principal prioridade, e nos comprometemos a melhorar continuamente a confiabilidade de nossos sistemas para corresponder à confiança que nossos clientes depositam em nós. Agradecemos aos nossos clientes pela sua paciência enquanto a nossa equipa trabalhou para resolver estes incidentes. Por favor, contacte a nossa equipa de apoio com quaisquer perguntas ou preocupações.
Traduzido automaticamente da atualização oficial do incidente.
Nível elevado de infra-estruturas falha nos empregos dos clientes
Início 7 Here 2026 da 14:27 UTC · 54m
IssuesMinor incident
Componentes afetados
Pipelines & Workflows
investigating
Estamos a investigar um aumento das infra-estruturas falha nos empregos dos clientes.
monitoring
Estamos a ver sinais de recuperação. Os tempos de espera do Docker Gen2 estão ligeiramente elevados e estamos a monitorizar.
resolved
Este incidente foi resolvido.
postmortem
## **Resumo #
Entre 1 de outubro e 8 de outubro de 2026, os clientes da CircleCI experimentaram cinco incidentes separados em que os trabalhos esperaram mais do que o normal para começar, ou não conseguiram começar. Três dos incidentes foram impulsionados pela disponibilidade de instância limitada do nosso provedor de nuvem. Uma foi causada por um problema de configuração em nossa infraestrutura de agendamento, e uma por limites de memória em um serviço interno, que levantamos durante o incidente.
* 1 de outubro, 07:57 a 10:24 UTC:** Os trabalhos do Docker Gen 2 esperaram até 30 minutos para começar. Um problema de configuração impediu os servidores de agendamento Gen 2 de usar seus discos locais de alto desempenho. Durante uma explosão no tráfego, os discos de retorno saturados e colocação de trabalho diminuiu.
* ** 7 de outubro, 13:27 - 14:06 UTC:** Empregos de máquinas esperaram mais do que o normal porque não conseguimos adquirir máquinas virtuais suficientes do nosso provedor de nuvem.
* ** 7 de outubro, 14:24 a 15:21 UTC:** Alguns trabalhos falharam com um erro de infraestrutura, e os fluxos de trabalho foram atrasados. O serviço que dá a cada trabalho sua configuração na inicialização ficou sem memória e reiniciado.
* ** 7 de outubro, 18:49 a 20:05 UTC:** Os trabalhos do Docker Gen 2 esperaram mais do que o normal porque não conseguimos obter instâncias suficientes do nosso provedor de nuvem.
* ** 8 de outubro, 12:48 - 16:00 UTC:** Trabalhos de máquinas Linux e trabalhos remotos do Docker esperaram até 50 minutos para começar. Nosso provedor de nuvem não tinha o suficiente do tipo de instância que solicitamos, e um defeito na lógica que escolhe um tipo de instância diferente nos impediu de usar alternativas.
Os empregos que esperavam durante estes incidentes foram atrasados, não perdidos. Clientes cujos trabalhos falharam com um erro de infraestrutura durante o incidente de 7 de outubro de 14:24 a 15:21 UTC pode repeti-los.
As páginas de status originais podem ser encontradas abaixo:
* [1 de Outubro - Atrasos iniciados Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g)
* [7 de outubro - Atraso no início das tarefas de trabalho de máquina] (https://status.circleci.com/incidents/tj6wdnfjwr64)
* [7 de Outubro - Nível elevado de falhas de infra-estruturas nos empregos dos clientes](https://status.circleci.com/incidents/0z31ldjd8m5v)
* [7 de outubro - Aumento dos tempos de espera para Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd)
* [8 de Outubro - Tempos de espera elevados para trabalhos de máquinas](https://status.circleci.com/incidents/jn756xtsy4xg)
Antecedentes
Todos os trabalhos que funcionam no CircleCI precisam de computação. De onde esse cálculo vem depende do executor.
Os trabalhos de Docker são executados em clusters de servidores que agendam trabalho em uma frota de instâncias. O programador é o software nos servidores que decidem qual instância executa cada trabalho. Os trabalhos de Docker Gen 2 funcionaram em um desses clusters no momento do incidente de 1 de outubro. Os empregos de Docker Gen 1 estão espalhados por vários clusters.
Trabalhos de máquinas, incluindo trabalhos remotos Docker, obter uma máquina virtual dedicada. Um trabalho remoto do Docker é tratado como um trabalho de máquina Linux desde submissão até provisionamento. O nosso serviço de fornecimento de máquinas requer cada máquina do nosso fornecedor de nuvem em uma das duas regiões que normalmente usamos para trabalhos de máquinas. Quando o provedor não pode fornecer o tipo de instância que solicitamos, o serviço recua: solicita um tipo de instância diferente, ou uma região diferente, de uma lista que mantemos. Um trabalho espera até que uma máquina esteja disponível.
Quando qualquer trabalho começa, ele pede um serviço de configuração de trabalho para sua configuração. Esse serviço funciona como um conjunto de pods, que são pequenas cópias do mesmo programa. Se muitos pods pararem, os pods restantes carregam mais carga, e os trabalhos não podem começar até que o serviço recupere.
Esses caminhos dependem de três tipos de capacidade: o rendimento de nossos sistemas de agendamento, o fornecimento de instâncias de nosso provedor de nuvem, e a memória e número de cópias dos serviços que iniciam trabalhos. Uma falha em qualquer um deles faz trabalhos esperar ou falhar.
* O que aconteceu *
\(Todas as vezes UTC\)
# # # Outubro 1: Docker Gen 2 trabalhos atrasados até 30 minutos #
Às 07:44, a atividade do disco nos servidores que agendam os trabalhos do Docker Gen 2 subiu para 90% da capacidade e ficou lá. Às 07:57, o número de empregos do Docker à espera para começar a crescer, e os tempos de espera aumentaram com ele. Um alerta automatizado chamou o engenheiro de plantão às 08:08. Declaramos um incidente às 08:42.
Às 08:43, os engenheiros identificaram alta latência do disco nos servidores de agendamento. Eles primeiro acreditavam que os discos eram muito lentos para a carga, então eles prepararam uma mudança para um tipo de disco mais rápido. Às 09:01, a equipe concordou em dois workstreams: mover os servidores para discos mais rápidos, e adicionar um segundo cluster Gen 2 para que os trabalhos fossem divididos em dois clusters.
Às 09:41, os engenheiros encontraram a causa raiz. Cada servidor de agendamento tem discos rápidos anexados diretamente a ele, e o escalonador é feito para manter seus dados de trabalho lá. Esses servidores são executados em uma imagem de sistema operacional enrijecida por segurança, e nessa imagem os discos rápidos não estavam sendo usados. O programador escreveu seus dados para discos mais lentos ligados à rede. O script que configura os discos rápidos falhou sem um erro, e uma lacuna no registro nesses servidores escondeu a falha. O tráfego do GN 2 também se tornou cada vez mais intenso. Os discos mais lentos saturaram durante essas explosões, e o programador caiu para trás.
Os tempos de espera chegaram às 09:54, quando os trabalhos na classe de recursos médios Gen 2 esperaram até 30 minutos. Às 09:55, os engenheiros aplicaram uma correção que configurou os discos rápidos corretamente. Às 10:11, o agendador começou a colocar trabalhos mais rápido, o que confirmou que os servidores poderiam acompanhar novos trabalhos. Tempos de espera para Gen 2 média caiu para 13 minutos em 10:14, 7 minutos em 10:17, e 1 minuto 30 segundos em 10:20. Mudamos a página de status para monitoramento às 10:24 e resolvemos o incidente às 10:45.
Às 11:20, o segundo cluster Gen 2 começou a executar trabalhos.
7 de Outubro, 13:27 a 14:06: Tempos elevados de espera para trabalhos de máquinas
Declaramos um incidente às 13:27 depois de vermos filas e esperas elevadas. Nós afixamos na página de status às 13:31. Às 13:31, os engenheiros viram que estávamos lutando para adquirir máquinas virtuais para trabalhos de máquinas, e que o número de trabalhos esperando para começar era alto principalmente para trabalhos de máquinas. Às 13:34, os tempos de espera foram elevados entre os executores.
Às 13:48, os tempos de espera começaram a se recuperar à medida que mais máquinas ficavam disponíveis, e resolvemos o incidente às 14:06.
## # ** 7 de outubro, 14:24 a 15:21: falhas de trabalho e atrasos no fluxo de trabalho**
Pouco depois que o incidente anterior foi marcado como resolvido, declaramos um novo incidente às 14:24 devido a uma queda acentuada no número de trabalhos submetidos aos nossos sistemas de execução. Às 14:26, os engenheiros viram que os pods do serviço de configuração de trabalho estavam reiniciando. Pods que reiniciam deixam menos cópias do serviço para responder aos pedidos, e trabalhos que não puderam recuperar sua configuração após tentativas repetidas falharam com um erro de infraestrutura. Fluxos de trabalho que já estavam em execução esperaram por atualizações de trabalhos que não tinham começado.
Às 14:35, os engenheiros aumentaram a quantidade de memória disponível para as vagens e aumentaram o número de vagens, o que deu ao serviço mais cópias para compartilhar a carga. Nós também aumentamos a quantidade de mensagens de trabalho disponíveis de memória começou a recuperar, e o número de mensagens fluindo através do nosso sistema de fluxo de trabalho retornou aos níveis normais. Às 14:44, mudamos a página de status para monitoramento.
Pods no serviço de configuração de tarefas atingiram seus limites de memória e reiniciaram. Aumentamos a alocação de memória e a contagem de cápsulas, e o serviço recuperado. Aos 15:13, nós aumentamos o número de casos em nossos clusters de Docker Gen 2 para que pudéssemos trabalhar através do atraso de empregos de espera rapidamente. Resolvemos o incidente às 15h21.
## ** 7 de Outubro, 18:49 a 20:05: Tempos de espera elevados para trabalhos do Docker Gen 2**
Declaramos um novo incidente às 18:49, depois de o Docker Gen 2 ter aparecido. Às 18:51, os engenheiros confirmaram que uma escassez de instâncias disponíveis nos impediu de adquirir bastante delas, o que aumentou os tempos de espera. Os tempos de espera diferiram pelo tamanho da classe de recursos.
Aos 19:52, os tempos médios de espera eram inferiores a uma hora antes, à medida que mais capacidade se tornava disponível, embora os picos breves continuassem, e movemos a página de status para monitoramento. Resolvemos o incidente às 20h05.
## # ** 8 de Outubro: a máquina Linux e os trabalhos remotos do Docker esperam até 50 minutos**
Declaramos um incidente às 12:48, depois de ver um grande número de trabalhos esperando para começar e longos tempos de espera para trabalhos de máquina e Docker remoto. Às 12:49, os engenheiros viram que nosso provedor de nuvem não podia fornecer instâncias suficientes. Os atrasos continuaram a subir enquanto investigamos.
Aos 13:13, começamos a examinar a lógica que escolhe um tipo de instância ou região diferente quando nossa primeira escolha não está disponível. Às 13:24, suspeitávamos que um defeito nessa lógica estava nos impedindo de usar outros tipos de instância em nossa região primária, então desativamos nossa região de retrocesso e confirmamos a causa do defeito. Os engenheiros começaram a trabalhar em uma correção e a implantaram às 14:49. O serviço começou a solicitar outros tipos de instância e começou máquinas em grande número. Às 14:58, a fila de empregos à espera de uma máquina caiu constantemente. Tempos médios de espera entre as classes de recursos continuaram a cair durante a próxima hora enquanto trabalhávamos através do backlog de trabalhos de espera.
Às 16:00, a fila de trabalhos à espera de uma máquina limpa e o número de trabalhos de espera voltaram ao normal. Mudamos a página de status para monitoramento às 16:09 e resolvemos o incidente às 16:35.
** ** Prevenção do Futuro e Melhoria do Processo **
Estamos tomando as seguintes medidas para fortalecer a resiliência dos tempos de início do trabalho, incluindo diversificação da oferta, lógica de retrocesso e detecção anterior.
** Estamos expandindo nossas regiões de computação.** Nos incidentes de 7 de outubro e 8 de outubro, nosso provedor de nuvem não poderia fornecer instâncias suficientes nas regiões que usamos. Estamos adicionando novas regiões à nossa lógica de retrocesso para lidar com picos de demanda que ultrapassam nossas regiões preferidas.
** Estamos fixando a lógica que escolhe um tipo de instância diferente.** Em 8 de outubro, um defeito impediu o serviço de fornecimento da máquina de usar outros tipos de instância na mesma região. Implantamos uma correção durante o incidente e agora estamos revisando e refatorando essa lógica como um todo, com testes, de modo que uma escassez de um tipo de instância se move para outro.
**Estamos expandindo os tipos de instância que oferecemos e garantindo capacidade adicional.** Estamos trabalhando com nosso provedor de nuvem para reservar capacidade adicional em nossas regiões existentes, e estamos adicionando tipos de instância que os trabalhos podem ser executados. A demanda da indústria por computação de alto desempenho está crescendo. Estamos diversificando onde e como nós fonte de capacidade para que nossos clientes são isolados da variação da oferta.
** Nós adicionamos um segundo cluster de Docker Gen 2 para que as explosões de tráfego sejam distribuídas em dois clusters.** Também estamos adicionando alertas sobre a saturação do disco do servidor de agendamento e sobre a rapidez com que o programador coloca trabalhos, e um alerta que dispara quando um servidor começa sem seus discos rápidos em uso. Fizemos o script de configuração de disco falhar com um erro, e restauramos o envio de log desses servidores para que um problema semelhante seja visível mais cedo.
A experiência do cliente é nossa principal prioridade, e nos comprometemos a melhorar continuamente a confiabilidade de nossos sistemas para corresponder à confiança que nossos clientes depositam em nós. Agradecemos aos nossos clientes pela sua paciência enquanto a nossa equipa trabalhou para resolver estes incidentes. Por favor, contacte a nossa equipa de apoio com quaisquer perguntas ou preocupações.
Traduzido automaticamente da atualização oficial do incidente.
Atraso no início das tarefas da máquina
Início 7 Here 2026 da 13:40 UTC · 26m
IssuesMinor incident
Componentes afetados
Machine Jobs
investigating
Os clientes podem estar experimentando tempos de espera elevados para tarefas de trabalho de máquina, estamos investigando a causa raiz e vamos atualizar quando soubermos mais.
monitoring
Vemos sinais de recuperação e acompanhamento da situação.
resolved
O incidente foi resolvido. Obrigado pela vossa paciência
postmortem
## **Resumo #
Entre 1 de outubro e 8 de outubro de 2026, os clientes da CircleCI experimentaram cinco incidentes separados em que os trabalhos esperaram mais do que o normal para começar, ou não conseguiram começar. Três dos incidentes foram impulsionados pela disponibilidade de instância limitada do nosso provedor de nuvem. Uma foi causada por um problema de configuração em nossa infraestrutura de agendamento, e uma por limites de memória em um serviço interno, que levantamos durante o incidente.
* 1 de outubro, 07:57 a 10:24 UTC:** Os trabalhos do Docker Gen 2 esperaram até 30 minutos para começar. Um problema de configuração impediu os servidores de agendamento Gen 2 de usar seus discos locais de alto desempenho. Durante uma explosão no tráfego, os discos de retorno saturados e colocação de trabalho diminuiu.
* ** 7 de outubro, 13:27 - 14:06 UTC:** Empregos de máquinas esperaram mais do que o normal porque não conseguimos adquirir máquinas virtuais suficientes do nosso provedor de nuvem.
* ** 7 de outubro, 14:24 a 15:21 UTC:** Alguns trabalhos falharam com um erro de infraestrutura, e os fluxos de trabalho foram atrasados. O serviço que dá a cada trabalho sua configuração na inicialização ficou sem memória e reiniciado.
* ** 7 de outubro, 18:49 a 20:05 UTC:** Os trabalhos do Docker Gen 2 esperaram mais do que o normal porque não conseguimos obter instâncias suficientes do nosso provedor de nuvem.
* ** 8 de outubro, 12:48 - 16:00 UTC:** Trabalhos de máquinas Linux e trabalhos remotos do Docker esperaram até 50 minutos para começar. Nosso provedor de nuvem não tinha o suficiente do tipo de instância que solicitamos, e um defeito na lógica que escolhe um tipo de instância diferente nos impediu de usar alternativas.
Os empregos que esperavam durante estes incidentes foram atrasados, não perdidos. Clientes cujos trabalhos falharam com um erro de infraestrutura durante o incidente de 7 de outubro de 14:24 a 15:21 UTC pode repeti-los.
As páginas de status originais podem ser encontradas abaixo:
* [1 de Outubro - Atrasos iniciados Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g)
* [7 de outubro - Atraso no início das tarefas de trabalho de máquina] (https://status.circleci.com/incidents/tj6wdnfjwr64)
* [7 de Outubro - Nível elevado de falhas de infra-estruturas nos empregos dos clientes](https://status.circleci.com/incidents/0z31ldjd8m5v)
* [7 de outubro - Aumento dos tempos de espera para Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd)
* [8 de Outubro - Tempos de espera elevados para trabalhos de máquinas](https://status.circleci.com/incidents/jn756xtsy4xg)
Antecedentes
Todos os trabalhos que funcionam no CircleCI precisam de computação. De onde esse cálculo vem depende do executor.
Os trabalhos de Docker são executados em clusters de servidores que agendam trabalho em uma frota de instâncias. O programador é o software nos servidores que decidem qual instância executa cada trabalho. Os trabalhos de Docker Gen 2 funcionaram em um desses clusters no momento do incidente de 1 de outubro. Os empregos de Docker Gen 1 estão espalhados por vários clusters.
Trabalhos de máquinas, incluindo trabalhos remotos Docker, obter uma máquina virtual dedicada. Um trabalho remoto do Docker é tratado como um trabalho de máquina Linux desde submissão até provisionamento. O nosso serviço de fornecimento de máquinas requer cada máquina do nosso fornecedor de nuvem em uma das duas regiões que normalmente usamos para trabalhos de máquinas. Quando o provedor não pode fornecer o tipo de instância que solicitamos, o serviço recua: solicita um tipo de instância diferente, ou uma região diferente, de uma lista que mantemos. Um trabalho espera até que uma máquina esteja disponível.
Quando qualquer trabalho começa, ele pede um serviço de configuração de trabalho para sua configuração. Esse serviço funciona como um conjunto de pods, que são pequenas cópias do mesmo programa. Se muitos pods pararem, os pods restantes carregam mais carga, e os trabalhos não podem começar até que o serviço recupere.
Esses caminhos dependem de três tipos de capacidade: o rendimento de nossos sistemas de agendamento, o fornecimento de instâncias de nosso provedor de nuvem, e a memória e número de cópias dos serviços que iniciam trabalhos. Uma falha em qualquer um deles faz trabalhos esperar ou falhar.
* O que aconteceu *
\(Todas as vezes UTC\)
# # # Outubro 1: Docker Gen 2 trabalhos atrasados até 30 minutos #
Às 07:44, a atividade do disco nos servidores que agendam os trabalhos do Docker Gen 2 subiu para 90% da capacidade e ficou lá. Às 07:57, o número de empregos do Docker à espera para começar a crescer, e os tempos de espera aumentaram com ele. Um alerta automatizado chamou o engenheiro de plantão às 08:08. Declaramos um incidente às 08:42.
Às 08:43, os engenheiros identificaram alta latência do disco nos servidores de agendamento. Eles primeiro acreditavam que os discos eram muito lentos para a carga, então eles prepararam uma mudança para um tipo de disco mais rápido. Às 09:01, a equipe concordou em dois workstreams: mover os servidores para discos mais rápidos, e adicionar um segundo cluster Gen 2 para que os trabalhos fossem divididos em dois clusters.
Às 09:41, os engenheiros encontraram a causa raiz. Cada servidor de agendamento tem discos rápidos anexados diretamente a ele, e o escalonador é feito para manter seus dados de trabalho lá. Esses servidores são executados em uma imagem de sistema operacional enrijecida por segurança, e nessa imagem os discos rápidos não estavam sendo usados. O programador escreveu seus dados para discos mais lentos ligados à rede. O script que configura os discos rápidos falhou sem um erro, e uma lacuna no registro nesses servidores escondeu a falha. O tráfego do GN 2 também se tornou cada vez mais intenso. Os discos mais lentos saturaram durante essas explosões, e o programador caiu para trás.
Os tempos de espera chegaram às 09:54, quando os trabalhos na classe de recursos médios Gen 2 esperaram até 30 minutos. Às 09:55, os engenheiros aplicaram uma correção que configurou os discos rápidos corretamente. Às 10:11, o agendador começou a colocar trabalhos mais rápido, o que confirmou que os servidores poderiam acompanhar novos trabalhos. Tempos de espera para Gen 2 média caiu para 13 minutos em 10:14, 7 minutos em 10:17, e 1 minuto 30 segundos em 10:20. Mudamos a página de status para monitoramento às 10:24 e resolvemos o incidente às 10:45.
Às 11:20, o segundo cluster Gen 2 começou a executar trabalhos.
7 de Outubro, 13:27 a 14:06: Tempos elevados de espera para trabalhos de máquinas
Declaramos um incidente às 13:27 depois de vermos filas e esperas elevadas. Nós afixamos na página de status às 13:31. Às 13:31, os engenheiros viram que estávamos lutando para adquirir máquinas virtuais para trabalhos de máquinas, e que o número de trabalhos esperando para começar era alto principalmente para trabalhos de máquinas. Às 13:34, os tempos de espera foram elevados entre os executores.
Às 13:48, os tempos de espera começaram a se recuperar à medida que mais máquinas ficavam disponíveis, e resolvemos o incidente às 14:06.
## # ** 7 de outubro, 14:24 a 15:21: falhas de trabalho e atrasos no fluxo de trabalho**
Pouco depois que o incidente anterior foi marcado como resolvido, declaramos um novo incidente às 14:24 devido a uma queda acentuada no número de trabalhos submetidos aos nossos sistemas de execução. Às 14:26, os engenheiros viram que os pods do serviço de configuração de trabalho estavam reiniciando. Pods que reiniciam deixam menos cópias do serviço para responder aos pedidos, e trabalhos que não puderam recuperar sua configuração após tentativas repetidas falharam com um erro de infraestrutura. Fluxos de trabalho que já estavam em execução esperaram por atualizações de trabalhos que não tinham começado.
Às 14:35, os engenheiros aumentaram a quantidade de memória disponível para as vagens e aumentaram o número de vagens, o que deu ao serviço mais cópias para compartilhar a carga. Nós também aumentamos a quantidade de mensagens de trabalho disponíveis de memória começou a recuperar, e o número de mensagens fluindo através do nosso sistema de fluxo de trabalho retornou aos níveis normais. Às 14:44, mudamos a página de status para monitoramento.
Pods no serviço de configuração de tarefas atingiram seus limites de memória e reiniciaram. Aumentamos a alocação de memória e a contagem de cápsulas, e o serviço recuperado. Aos 15:13, nós aumentamos o número de casos em nossos clusters de Docker Gen 2 para que pudéssemos trabalhar através do atraso de empregos de espera rapidamente. Resolvemos o incidente às 15h21.
## ** 7 de Outubro, 18:49 a 20:05: Tempos de espera elevados para trabalhos do Docker Gen 2**
Declaramos um novo incidente às 18:49, depois de o Docker Gen 2 ter aparecido. Às 18:51, os engenheiros confirmaram que uma escassez de instâncias disponíveis nos impediu de adquirir bastante delas, o que aumentou os tempos de espera. Os tempos de espera diferiram pelo tamanho da classe de recursos.
Aos 19:52, os tempos médios de espera eram inferiores a uma hora antes, à medida que mais capacidade se tornava disponível, embora os picos breves continuassem, e movemos a página de status para monitoramento. Resolvemos o incidente às 20h05.
## # ** 8 de Outubro: a máquina Linux e os trabalhos remotos do Docker esperam até 50 minutos**
Declaramos um incidente às 12:48, depois de ver um grande número de trabalhos esperando para começar e longos tempos de espera para trabalhos de máquina e Docker remoto. Às 12:49, os engenheiros viram que nosso provedor de nuvem não podia fornecer instâncias suficientes. Os atrasos continuaram a subir enquanto investigamos.
Aos 13:13, começamos a examinar a lógica que escolhe um tipo de instância ou região diferente quando nossa primeira escolha não está disponível. Às 13:24, suspeitávamos que um defeito nessa lógica estava nos impedindo de usar outros tipos de instância em nossa região primária, então desativamos nossa região de retrocesso e confirmamos a causa do defeito. Os engenheiros começaram a trabalhar em uma correção e a implantaram às 14:49. O serviço começou a solicitar outros tipos de instância e começou máquinas em grande número. Às 14:58, a fila de empregos à espera de uma máquina caiu constantemente. Tempos médios de espera entre as classes de recursos continuaram a cair durante a próxima hora enquanto trabalhávamos através do backlog de trabalhos de espera.
Às 16:00, a fila de trabalhos à espera de uma máquina limpa e o número de trabalhos de espera voltaram ao normal. Mudamos a página de status para monitoramento às 16:09 e resolvemos o incidente às 16:35.
** ** Prevenção do Futuro e Melhoria do Processo **
Estamos tomando as seguintes medidas para fortalecer a resiliência dos tempos de início do trabalho, incluindo diversificação da oferta, lógica de retrocesso e detecção anterior.
** Estamos expandindo nossas regiões de computação.** Nos incidentes de 7 de outubro e 8 de outubro, nosso provedor de nuvem não poderia fornecer instâncias suficientes nas regiões que usamos. Estamos adicionando novas regiões à nossa lógica de retrocesso para lidar com picos de demanda que ultrapassam nossas regiões preferidas.
** Estamos fixando a lógica que escolhe um tipo de instância diferente.** Em 8 de outubro, um defeito impediu o serviço de fornecimento da máquina de usar outros tipos de instância na mesma região. Implantamos uma correção durante o incidente e agora estamos revisando e refatorando essa lógica como um todo, com testes, de modo que uma escassez de um tipo de instância se move para outro.
**Estamos expandindo os tipos de instância que oferecemos e garantindo capacidade adicional.** Estamos trabalhando com nosso provedor de nuvem para reservar capacidade adicional em nossas regiões existentes, e estamos adicionando tipos de instância que os trabalhos podem ser executados. A demanda da indústria por computação de alto desempenho está crescendo. Estamos diversificando onde e como nós fonte de capacidade para que nossos clientes são isolados da variação da oferta.
** Nós adicionamos um segundo cluster de Docker Gen 2 para que as explosões de tráfego sejam distribuídas em dois clusters.** Também estamos adicionando alertas sobre a saturação do disco do servidor de agendamento e sobre a rapidez com que o programador coloca trabalhos, e um alerta que dispara quando um servidor começa sem seus discos rápidos em uso. Fizemos o script de configuração de disco falhar com um erro, e restauramos o envio de log desses servidores para que um problema semelhante seja visível mais cedo.
A experiência do cliente é nossa principal prioridade, e nos comprometemos a melhorar continuamente a confiabilidade de nossos sistemas para corresponder à confiança que nossos clientes depositam em nós. Agradecemos aos nossos clientes pela sua paciência enquanto a nossa equipa trabalhou para resolver estes incidentes. Por favor, contacte a nossa equipa de apoio com quaisquer perguntas ou preocupações.
Traduzido automaticamente da atualização oficial do incidente.
Atrasos em pipelines, fluxos de trabalho, dados de IU e notificações
Início 6 Here 2026 da 16:00 UTC · 5h 18m
OutageMajor incident
Componentes afetados
Pipelines & WorkflowsNotifications & Status Updates
investigating
O que está impactado
Clientes usando pipelines e fluxos de trabalho do CircleCI, incluindo exibição de dados de UI, notificações de saída e webhooks de saída.
O que você pode esperar
Atrasos em pipelines sendo criados e em fluxos de trabalho e trabalhos começando. Dados de trabalho, fluxo de trabalho e pipeline podem levar até 15 minutos para aparecer na UI. Notificações de saída e webhooks são adiadas até 1 minuto.
Próxima atualização
Nós forneceremos outra atualização dentro de 30 minutos ou como temos mais informações para compartilhar.
investigating
Desde 15:47 UTC, os clientes também podem ver trabalhos fracassados, além dos atrasos relatados anteriormente. Nossos engenheiros continuam investigando e mitigando o problema.
identified
A partir de 16:02 UTC, os pipelines estão falhando completamente, então nenhum novo fluxo de trabalho ou trabalhos estão funcionando neste momento. Isto é para além dos atrasos e fracassos de trabalhos relatados anteriormente. Nossos engenheiros continuam trabalhando na mitigação da questão, e compartilharemos mais informações assim que a tivermos.
identified
A partir das 16:39 UTC, estamos começando a ver a recuperação de novos gasodutos e fluxos de trabalho sendo enviados, e os trabalhos estão começando a funcionar novamente. Nossos engenheiros continuam trabalhando na recuperação e compartilharão mais informações assim que a tivermos.
identified
Enquanto Pipelines, fluxos de trabalho e trabalhos estão funcionando novamente, os clientes podem continuar a ver atrasos mais longos do que o normal entre trabalhos em um fluxo de trabalho, e notificações de saída são adiadas em aproximadamente 1 minuto. Notificações e atualizações de status do seu sistema de controle de versão estão começando a sair novamente.
Os nossos engenheiros continuam a trabalhar para uma recuperação completa.
identified
Os clientes continuam a experimentar atrasos mais longos do que o normal entre os trabalhos em um fluxo de trabalho, bem como atrasos nas notificações de saída.
Agradecemos a sua paciência, enquanto nossos engenheiros continuam a investigar e trabalhar na atenuação do problema. Vamos compartilhar outra atualização nos próximos 30 minutos, ou mais cedo se mais informações estiverem disponíveis.
identified
Os clientes continuam a experimentar atrasos mais longos do que o habitual antes do início dos fluxos de trabalho e das tarefas, em alguns casos até aproximadamente 30 minutos. Isto é melhorado em relação ao início do incidente, mas os atrasos permanecem. Os atrasos nas notificações de saída melhoraram.
Agradecemos a sua paciência enquanto nossos engenheiros continuam a trabalhar para restaurar os horários normais de início do trabalho. Vamos compartilhar outra atualização nos próximos 30 minutos, ou mais cedo se mais informações estiverem disponíveis.
identified
Os clientes continuam a experimentar atrasos. A maioria agora está começando em aproximadamente 20 minutos, melhorou de aproximadamente 40 minutos antes do incidente. Um número muito pequeno de fluxos de trabalho pode ter esperado mais de 1 hora.
Nossos engenheiros fizeram mudanças que melhoraram a estabilidade do serviço, e o atraso restante é devido a um atraso de trabalho que se desenvolveu durante o incidente. O atraso está a diminuir, e estamos focados em clareá-lo mais rapidamente. Partilharemos mais informações à medida que o progresso continuar.
Agradecemos a sua paciência enquanto nossos engenheiros trabalham através do atraso. Vamos compartilhar outra atualização nos próximos 30 minutos, ou mais cedo se mais informações estiverem disponíveis.
identified
Atrasos para fluxos de trabalho e trabalhos para começar estão continuando a diminuir. A maioria agora está começando em aproximadamente 10 minutos, melhorou de aproximadamente 40 minutos antes do incidente. Um número muito pequeno de fluxos de trabalho pode ter esperado mais de 1 hora. Se o seu trabalho não começou, por favor, repita o trabalho. Os atrasos nas notificações de saída melhoraram.
O atraso restante é devido a um atraso de trabalho que se acumulou durante o incidente, e esse atraso reduziu em mais da metade. Esperamos que o atraso seja limpo em aproximadamente 15 minutos. Vamos compartilhar outra atualização uma vez que tenha liberado, ou dentro dos próximos 30 minutos, o mais tardar.
identified
O backlog do trabalho atrasado foi limpo, e os fluxos de trabalho estão começando novamente sem atrasos nas notificações. No entanto, os clientes que usam trabalhos do Docker e Linux em várias classes de recursos, incluindo média, grande e 2xlarge gen2, podem agora ver trabalhos esperando na fila por alguns minutos antes de começarem. Os nossos engenheiros continuam a trabalhar na atenuação desta questão. Se o seu trabalho não começou, por favor, repita o trabalho.
Agradecemos sua paciência enquanto nossos engenheiros trabalham nisso. Vamos compartilhar outra atualização nos próximos 30 minutos, ou mais cedo se mais informações estiverem disponíveis.
monitoring
Fluxos de trabalho e trabalhos estão começando normalmente, e as horas de espera para trabalhos do Docker e Linux retornaram ao normal. Nossos engenheiros continuam a monitorar esta questão. Se o seu trabalho não começou, por favor, repita o trabalho.
Agradecemos sua paciência enquanto nossos engenheiros trabalham nisso. Vamos compartilhar outra atualização nos próximos 30 minutos, ou mais cedo se mais informações estiverem disponíveis.
resolved
Entre aproximadamente 15:30 UTC e 20:30 UTC em 6 de outubro de 2026, os clientes sofreram atrasos e falhas afetando pipelines, fluxos de trabalho e empregos.
De aproximadamente 16:02 UTC a 16:39 UTC, os gasodutos estavam falhando e nenhum novo fluxo de trabalho ou trabalhos poderia começar. Após a retomada do serviço, os fluxos de trabalho e as tarefas continuaram a começar com atrasos até aproximadamente 20:00 UTC. Os tempos de início mediam até aproximadamente 40 minutos no seu pico, e um número muito pequeno de fluxos de trabalho esperou mais de 1 hora. Notificações de saída e webhooks também foram adiadas até aproximadamente 19:00 UTC, normalmente por cerca de um minuto.
À medida que o atraso no trabalho foi diminuindo, o aumento da demanda fez pressão sobre nossa capacidade de execução, causando mais atrasos para os trabalhos do Docker e Linux. De aproximadamente 19:45 UTC a 20:30 UTC, estes trabalhos esperaram na fila mais tempo do que o habitual antes de começar. No pico, cerca de 20:05 UTC, espera chegou a aproximadamente 8 minutos para 2xlarge gen2, 6 minutos para xlarge gen2, e menos de 5 minutos para algumas outras classes de recursos.
O problema foi resolvido, e toda a funcionalidade afetada voltou ao normal. Clientes cujos trabalhos falharam durante esta janela podem repetir trabalhos afetados. Agradecemos a sua paciência, enquanto nossa equipe trabalhou na implementação de uma correção.
postmortem
# # Resumo
Em 6 de outubro de 2026, das 15:30 às 20:30 UTC, os clientes da CircleCI sofreram atrasos na criação de gasodutos e no início de fluxos de trabalho e empregos. De 15:48 a 16:38 UTC, nenhum fluxo de trabalho ou trabalhos iniciados, e pipelines disparados de 16:02 UTC falhou. Atrasos mais curtos e intermitentes começaram mais cedo, às 13:30 UTC. Os dados na UI CircleCI, notificações e atualizações de status de commit para provedores de controle de versão também foram atrasados.
O incidente começou no banco de dados por trás do nosso serviço de orquestração de fluxo de trabalho, que coordena cada pipeline, fluxo de trabalho e trabalho em CircleCI. A manutenção de rotina nas maiores tabelas do banco de dados escreveu registros de transações mais rápido do que o banco de dados poderia arquivá-los, e os registros preencheram o volume de armazenamento reservado para eles. Para impedir que o banco de dados se tornasse somente leitura, nossos engenheiros mudaram os registros para o volume de armazenamento principal do banco de dados. Essa jogada desligou a base de dados durante 50 minutos. Quando o banco de dados voltou, ele processou trabalho em cerca de metade de sua taxa normal até que nossos engenheiros mudaram uma configuração de banco de dados em 18:19 UTC. Em seguida, trabalhamos através do backlog, e os tempos de início do trabalho voltaram ao normal às 20:30 UTC.
Os clientes cujos trabalhos falharam durante esta janela podem repeti- los.
A página de status original pode ser encontrada [aqui](https://status.circleci.com/incidentes/z4hbq8h49j8c).
# # Fundo
Quando se desencadeia um gasoduto, o CircleCI entrega-o a um serviço de orquestração de fluxo de trabalho. Esse serviço acompanha o estado de cada fluxo de trabalho e trabalho, decide quando cada trabalho está pronto para ser executado e passa trabalhos prontos para nossa frota de execução. Ele também impulsiona os dados de trabalho que você vê na UI e as notificações e commit status que enviamos quando o trabalho termina.
O serviço de orquestração armazena seu estado em uma base de dados. O banco de dados escreve todas as alterações em um registro de transação antes de aplicá-lo, e mantém esses registros em um volume de armazenamento dedicado. Arquiva os logs continuamente para poder reutilizar esse espaço. Se o arquivamento ficar para trás e o volume preencher, o banco de dados para de aceitar as gravações, e nenhum novo trabalho pode avançar.
O banco de dados também executa um processo de manutenção periódica \(autovacuums\) em cada tabela para manter seus registros internos válidos ao longo do tempo. Em uma tabela muito grande, este processo lê todas as páginas da tabela e escreve um grande volume de registros de transação.
# # O Que Aconteceu
\(Todas as vezes UTC\)
De 10:02 em 6 de outubro, nosso monitoramento levantou alertas de curta duração sobre erros no serviço de orquestração. Cada alerta foi apagado em 15 minutos. Nossos engenheiros tinham visto alertas semelhantes antes, e o sistema não mostrou nenhum outro sinal de estresse, então eles seguiram o manual de execução cada vez, e cada alerta limpo em seu próprio caminho e também começou a trabalhar para tornar os alertas menos sensíveis.
Por volta das 12:40, junto com a carga de trabalho regular que gera seus próprios registros de transação, o processo de manutenção em várias das maiores tabelas do banco de dados começou a escrever logs de transação adicionais mais rápido do que o banco de dados poderia arquivá-los, e o volume de registro começou a preencher.
Às 13:30, o serviço de orquestração começou a abrandar. Por volta das 15:30, alguns oleodutos e trabalhos demoraram mais tempo para começar, em rajadas curtas. Às 13:35, nosso monitoramento voltou a alertar, desta vez ao lado de alertas relacionados de vários outros serviços. Os engenheiros de infraestrutura seguiram os registros de alerta, limpando alguns dos alertas. Os alertas retornaram por volta das 14:30 e, depois de investigar mais, declaramos um incidente às 14:54. Devíamos ter reconhecido a combinação de alertas mais cedo, e cobrimos como estamos a corrigir isso abaixo.
Após declarar o incidente, nossos engenheiros rastrearam a desaceleração para o processo de manutenção \(anti-wraparound autovacuum\). O banco de dados reinicia este processo automaticamente se ele for cancelado, então nossos engenheiros mudaram suas configurações para ajudá-lo a terminar mais rápido. Em 15:30, os atrasos foram contínuos, e alguns trabalhos começaram a falhar.
Às 15:43, o volume do diário de transações estava próximo da totalidade. Se preenchido, o banco de dados iria parar de aceitar escreve e nenhum trabalho poderia ser executado. Nossos engenheiros decidiram mover os registros de transações para o volume de armazenamento principal do banco de dados, que tinha muito espaço livre. A mudança exigia que o banco de dados ficasse offline, e não podíamos prever com antecedência quanto tempo isso levaria.
A mudança começou às 15:47. De 15:48 a 16:38, o serviço de orquestração não podia processar nenhum trabalho. Os clientes ainda poderiam desencadear oleodutos, mas nenhum fluxo de trabalho ou trabalhos iniciados, e a partir 16:02 novos oleodutos disparados falhou. Nós postamos em nossa página de status às 15:58 e elevá-lo a uma grande parada às 16:20. Enquanto a base de dados estava offline, os nossos engenheiros prepararam uma base de dados de substituição como reserva. A base de dados original voltou primeiro, por isso mantivemo-la em serviço.
Às 16:38, o banco de dados voltou online e o trabalho começou a fluir novamente. Com registros de transações e dados regulares agora compartilhando o mesmo armazenamento, o banco de dados correu mais lentamente do que antes. De 16:38 a 18:19, o serviço de orquestração processou o trabalho em cerca da metade de sua taxa normal, e os trabalhos esperaram dezenas de minutos para começar, até cerca de 50 minutos no máximo. Durante esse tempo, o banco de dados teve que terminar arquivando seu backlog de registros de transações antes que pudéssemos movê-los de volta para um volume dedicado. Também investigamos e implementamos várias mudanças de parâmetros de banco de dados para impedir que novas operações de manutenção sejam iniciadas e preparadas para reduzir o trabalho que chega ao serviço. Juntamente com o banco de dados de substituição, também preparamos uma pilha completa do serviço durante esse tempo para que pudéssemos passar para ele em risco de perda de dados e optamos por esse movimento.
Às 18:19, nossos engenheiros mudaram uma configuração de banco de dados para cortar o tempo que cada gravação passou esperando no armazenamento. A velocidade de processamento recuperou, e o atraso começou a limpar. Para clareá-lo mais rápido, adicionamos banco de dados e capacidade de servidor aos sistemas que entregam tarefas à nossa frota de execução. Por volta das 19:55, novos empregos começaram novamente a tempo.
O atraso chegou à nossa frota de execução. De 19:49 a 20:30, alguns trabalhos do Docker em classes de recursos maiores esperaram até cerca de 10 minutos para começar enquanto a capacidade aumentava. Às 20h30, os horários de início do trabalho voltaram ao normal. Movemos a página de status para monitoramento às 20:32 e resolvemos o incidente às 21:19.
Cerca de 3.500 empregos não começaram durante o incidente. Os clientes podem repetir estes trabalhos. Não encontrámos provas de que o CircleCI tenha trabalhado mais do que uma vez. Os clientes que redefiniram um fluxo de trabalho enquanto a execução original ainda estava atrasada podem ter visto ambas as execuções completas. Os clientes do plano anual podem trabalhar com sua equipe de conta para revisar o uso.
# # Prevenção futura e melhoria do processo
Estamos tomando as seguintes medidas para evitar uma recorrência e melhorar nosso tempo de resposta:
** Estamos adicionando alertas sobre as condições que causaram este incidente.** A nossa monitorização registou o abrandamento, mas não tivemos qualquer alerta sobre o volume total do registo de transacções ou sobre o atraso do arquivamento. Estamos adicionando alertas em ambos, juntamente com alertas sobre a manutenção do banco de dados que os impulsiona, para que possamos agir mais cedo. Também estamos revisitando todos os nossos alertas para garantir que alertas barulhentos ou sensíveis não escondam problemas reais.
**Estamos sintonizando como o processo de manutenção \(autovacuum\) é executado em nosso banco de dados.** Estamos olhando para a frequência e a agressividade com que os autovacuums funcionam em nossa base de dados. Nós também estamos rastreando o tamanho destas tabelas ao longo do tempo para que eles permaneçam dentro de limites seguros.
** Estamos removendo o gargalo de log de transação única.** Todos os registros do serviço de orquestração atualmente passam por um banco de dados e um registro de transação, então quando esse registro caiu para trás, cada pipeline, fluxo de trabalho e trabalho diminuiu com ele. Estamos avaliando duas abordagens: dividir o serviço em várias instâncias de banco de dados, cada uma com seu próprio registro de transação, e movê-lo para um banco de dados distribuído construído para espalhar escreve em muitos nós. Qualquer abordagem limitaria o efeito de um atraso a parte da carga de trabalho.
** Estamos fazendo nossos sistemas esperar o serviço de orquestração se recuperar.** Durante o incidente, alguns empregos falharam porque os nossos sistemas desistiram depois de tentar novamente. Estamos a trabalhar em mudar esse comportamento.
** Estamos melhorando nossas atualizações de página de status durante longos incidentes.** Os clientes disseram-nos que as nossas primeiras actualizações não deram detalhes suficientes. Estamos atualizando nossas orientações para que as atualizações incluam impacto específico e temporização mais cedo.
□
A experiência do cliente é nossa principal prioridade, e nos comprometemos a melhorar continuamente a confiabilidade de nossos sistemas para corresponder à confiança que nossos clientes depositam em nós. Agradecemos aos nossos clientes pela sua paciência enquanto a nossa equipa trabalhou para resolver este incidente. Por favor, contacte a nossa equipa de apoio com quaisquer perguntas ou preocupações.
Traduzido automaticamente da atualização oficial do incidente.
Atrasos ao iniciar as tarefas de Docker Gen 2
Início 1 Here 2026 da 09:06 UTC · 1h 39m
IssuesMinor incident
Componentes afetados
Docker Jobs
investigating
Os clientes podem experimentar atrasos no início do Docker Gen 2 Jobs. Estamos trabalhando para aumentar o rendimento do sistema para acomodar isso.
identified
Identificamos a causa raiz e estamos trabalhando ativamente em uma correção. Obrigado pela vossa paciência.
identified
Foi feita uma correção e estamos a começar a observar a recuperação.
monitoring
Estamos vendo os tempos de fila retornarem aos níveis normais, e continuar monitorando.
resolved
Este incidente foi resolvido.
postmortem
## **Resumo #
Entre 1 de outubro e 8 de outubro de 2026, os clientes da CircleCI experimentaram cinco incidentes separados em que os trabalhos esperaram mais do que o normal para começar, ou não conseguiram começar. Três dos incidentes foram impulsionados pela disponibilidade de instância limitada do nosso provedor de nuvem. Uma foi causada por um problema de configuração em nossa infraestrutura de agendamento, e uma por limites de memória em um serviço interno, que levantamos durante o incidente.
* 1 de outubro, 07:57 a 10:24 UTC:** Os trabalhos do Docker Gen 2 esperaram até 30 minutos para começar. Um problema de configuração impediu os servidores de agendamento Gen 2 de usar seus discos locais de alto desempenho. Durante uma explosão no tráfego, os discos de retorno saturados e colocação de trabalho diminuiu.
* ** 7 de outubro, 13:27 - 14:06 UTC:** Empregos de máquinas esperaram mais do que o normal porque não conseguimos adquirir máquinas virtuais suficientes do nosso provedor de nuvem.
* ** 7 de outubro, 14:24 a 15:21 UTC:** Alguns trabalhos falharam com um erro de infraestrutura, e os fluxos de trabalho foram atrasados. O serviço que dá a cada trabalho sua configuração na inicialização ficou sem memória e reiniciado.
* ** 7 de outubro, 18:49 a 20:05 UTC:** Os trabalhos do Docker Gen 2 esperaram mais do que o normal porque não conseguimos obter instâncias suficientes do nosso provedor de nuvem.
* ** 8 de outubro, 12:48 - 16:00 UTC:** Trabalhos de máquinas Linux e trabalhos remotos do Docker esperaram até 50 minutos para começar. Nosso provedor de nuvem não tinha o suficiente do tipo de instância que solicitamos, e um defeito na lógica que escolhe um tipo de instância diferente nos impediu de usar alternativas.
Os empregos que esperavam durante estes incidentes foram atrasados, não perdidos. Clientes cujos trabalhos falharam com um erro de infraestrutura durante o incidente de 7 de outubro de 14:24 a 15:21 UTC pode repeti-los.
As páginas de status originais podem ser encontradas abaixo:
* [1 de Outubro - Atrasos iniciados Gen 2 Docker Jobs](https://status.circleci.com/incidents/22mrv46g6n7g)
* [7 de outubro - Atraso no início das tarefas de trabalho de máquina] (https://status.circleci.com/incidents/tj6wdnfjwr64)
* [7 de Outubro - Nível elevado de falhas de infra-estruturas nos empregos dos clientes](https://status.circleci.com/incidents/0z31ldjd8m5v)
* [7 de outubro - Aumento dos tempos de espera para Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd)
* [8 de Outubro - Tempos de espera elevados para trabalhos de máquinas](https://status.circleci.com/incidents/jn756xtsy4xg)
Antecedentes
Todos os trabalhos que funcionam no CircleCI precisam de computação. De onde esse cálculo vem depende do executor.
Os trabalhos de Docker são executados em clusters de servidores que agendam trabalho em uma frota de instâncias. O programador é o software nos servidores que decidem qual instância executa cada trabalho. Os trabalhos de Docker Gen 2 funcionaram em um desses clusters no momento do incidente de 1 de outubro. Os empregos de Docker Gen 1 estão espalhados por vários clusters.
Trabalhos de máquinas, incluindo trabalhos remotos Docker, obter uma máquina virtual dedicada. Um trabalho remoto do Docker é tratado como um trabalho de máquina Linux desde submissão até provisionamento. O nosso serviço de fornecimento de máquinas requer cada máquina do nosso fornecedor de nuvem em uma das duas regiões que normalmente usamos para trabalhos de máquinas. Quando o provedor não pode fornecer o tipo de instância que solicitamos, o serviço recua: solicita um tipo de instância diferente, ou uma região diferente, de uma lista que mantemos. Um trabalho espera até que uma máquina esteja disponível.
Quando qualquer trabalho começa, ele pede um serviço de configuração de trabalho para sua configuração. Esse serviço funciona como um conjunto de pods, que são pequenas cópias do mesmo programa. Se muitos pods pararem, os pods restantes carregam mais carga, e os trabalhos não podem começar até que o serviço recupere.
Esses caminhos dependem de três tipos de capacidade: o rendimento de nossos sistemas de agendamento, o fornecimento de instâncias de nosso provedor de nuvem, e a memória e número de cópias dos serviços que iniciam trabalhos. Uma falha em qualquer um deles faz trabalhos esperar ou falhar.
* O que aconteceu *
\(Todas as vezes UTC\)
# # # Outubro 1: Docker Gen 2 trabalhos atrasados até 30 minutos #
Às 07:44, a atividade do disco nos servidores que agendam os trabalhos do Docker Gen 2 subiu para 90% da capacidade e ficou lá. Às 07:57, o número de empregos do Docker à espera para começar a crescer, e os tempos de espera aumentaram com ele. Um alerta automatizado chamou o engenheiro de plantão às 08:08. Declaramos um incidente às 08:42.
Às 08:43, os engenheiros identificaram alta latência do disco nos servidores de agendamento. Eles primeiro acreditavam que os discos eram muito lentos para a carga, então eles prepararam uma mudança para um tipo de disco mais rápido. Às 09:01, a equipe concordou em dois workstreams: mover os servidores para discos mais rápidos, e adicionar um segundo cluster Gen 2 para que os trabalhos fossem divididos em dois clusters.
Às 09:41, os engenheiros encontraram a causa raiz. Cada servidor de agendamento tem discos rápidos anexados diretamente a ele, e o escalonador é feito para manter seus dados de trabalho lá. Esses servidores são executados em uma imagem de sistema operacional enrijecida por segurança, e nessa imagem os discos rápidos não estavam sendo usados. O programador escreveu seus dados para discos mais lentos ligados à rede. O script que configura os discos rápidos falhou sem um erro, e uma lacuna no registro nesses servidores escondeu a falha. O tráfego do GN 2 também se tornou cada vez mais intenso. Os discos mais lentos saturaram durante essas explosões, e o programador caiu para trás.
Os tempos de espera chegaram às 09:54, quando os trabalhos na classe de recursos médios Gen 2 esperaram até 30 minutos. Às 09:55, os engenheiros aplicaram uma correção que configurou os discos rápidos corretamente. Às 10:11, o agendador começou a colocar trabalhos mais rápido, o que confirmou que os servidores poderiam acompanhar novos trabalhos. Tempos de espera para Gen 2 média caiu para 13 minutos em 10:14, 7 minutos em 10:17, e 1 minuto 30 segundos em 10:20. Mudamos a página de status para monitoramento às 10:24 e resolvemos o incidente às 10:45.
Às 11:20, o segundo cluster Gen 2 começou a executar trabalhos.
7 de Outubro, 13:27 a 14:06: Tempos elevados de espera para trabalhos de máquinas
Declaramos um incidente às 13:27 depois de vermos filas e esperas elevadas. Nós afixamos na página de status às 13:31. Às 13:31, os engenheiros viram que estávamos lutando para adquirir máquinas virtuais para trabalhos de máquinas, e que o número de trabalhos esperando para começar era alto principalmente para trabalhos de máquinas. Às 13:34, os tempos de espera foram elevados entre os executores.
Às 13:48, os tempos de espera começaram a se recuperar à medida que mais máquinas ficavam disponíveis, e resolvemos o incidente às 14:06.
## # ** 7 de outubro, 14:24 a 15:21: falhas de trabalho e atrasos no fluxo de trabalho**
Pouco depois que o incidente anterior foi marcado como resolvido, declaramos um novo incidente às 14:24 devido a uma queda acentuada no número de trabalhos submetidos aos nossos sistemas de execução. Às 14:26, os engenheiros viram que os pods do serviço de configuração de trabalho estavam reiniciando. Pods que reiniciam deixam menos cópias do serviço para responder aos pedidos, e trabalhos que não puderam recuperar sua configuração após tentativas repetidas falharam com um erro de infraestrutura. Fluxos de trabalho que já estavam em execução esperaram por atualizações de trabalhos que não tinham começado.
Às 14:35, os engenheiros aumentaram a quantidade de memória disponível para as vagens e aumentaram o número de vagens, o que deu ao serviço mais cópias para compartilhar a carga. Nós também aumentamos a quantidade de mensagens de trabalho disponíveis de memória começou a recuperar, e o número de mensagens fluindo através do nosso sistema de fluxo de trabalho retornou aos níveis normais. Às 14:44, mudamos a página de status para monitoramento.
Pods no serviço de configuração de tarefas atingiram seus limites de memória e reiniciaram. Aumentamos a alocação de memória e a contagem de cápsulas, e o serviço recuperado. Aos 15:13, nós aumentamos o número de casos em nossos clusters de Docker Gen 2 para que pudéssemos trabalhar através do atraso de empregos de espera rapidamente. Resolvemos o incidente às 15h21.
## ** 7 de Outubro, 18:49 a 20:05: Tempos de espera elevados para trabalhos do Docker Gen 2**
Declaramos um novo incidente às 18:49, depois de o Docker Gen 2 ter aparecido. Às 18:51, os engenheiros confirmaram que uma escassez de instâncias disponíveis nos impediu de adquirir bastante delas, o que aumentou os tempos de espera. Os tempos de espera diferiram pelo tamanho da classe de recursos.
Aos 19:52, os tempos médios de espera eram inferiores a uma hora antes, à medida que mais capacidade se tornava disponível, embora os picos breves continuassem, e movemos a página de status para monitoramento. Resolvemos o incidente às 20h05.
## # ** 8 de Outubro: a máquina Linux e os trabalhos remotos do Docker esperam até 50 minutos**
Declaramos um incidente às 12:48, depois de ver um grande número de trabalhos esperando para começar e longos tempos de espera para trabalhos de máquina e Docker remoto. Às 12:49, os engenheiros viram que nosso provedor de nuvem não podia fornecer instâncias suficientes. Os atrasos continuaram a subir enquanto investigamos.
Aos 13:13, começamos a examinar a lógica que escolhe um tipo de instância ou região diferente quando nossa primeira escolha não está disponível. Às 13:24, suspeitávamos que um defeito nessa lógica estava nos impedindo de usar outros tipos de instância em nossa região primária, então desativamos nossa região de retrocesso e confirmamos a causa do defeito. Os engenheiros começaram a trabalhar em uma correção e a implantaram às 14:49. O serviço começou a solicitar outros tipos de instância e começou máquinas em grande número. Às 14:58, a fila de empregos à espera de uma máquina caiu constantemente. Tempos médios de espera entre as classes de recursos continuaram a cair durante a próxima hora enquanto trabalhávamos através do backlog de trabalhos de espera.
Às 16:00, a fila de trabalhos à espera de uma máquina limpa e o número de trabalhos de espera voltaram ao normal. Mudamos a página de status para monitoramento às 16:09 e resolvemos o incidente às 16:35.
** ** Prevenção do Futuro e Melhoria do Processo **
Estamos tomando as seguintes medidas para fortalecer a resiliência dos tempos de início do trabalho, incluindo diversificação da oferta, lógica de retrocesso e detecção anterior.
** Estamos expandindo nossas regiões de computação.** Nos incidentes de 7 de outubro e 8 de outubro, nosso provedor de nuvem não poderia fornecer instâncias suficientes nas regiões que usamos. Estamos adicionando novas regiões à nossa lógica de retrocesso para lidar com picos de demanda que ultrapassam nossas regiões preferidas.
** Estamos fixando a lógica que escolhe um tipo de instância diferente.** Em 8 de outubro, um defeito impediu o serviço de fornecimento da máquina de usar outros tipos de instância na mesma região. Implantamos uma correção durante o incidente e agora estamos revisando e refatorando essa lógica como um todo, com testes, de modo que uma escassez de um tipo de instância se move para outro.
**Estamos expandindo os tipos de instância que oferecemos e garantindo capacidade adicional.** Estamos trabalhando com nosso provedor de nuvem para reservar capacidade adicional em nossas regiões existentes, e estamos adicionando tipos de instância que os trabalhos podem ser executados. A demanda da indústria por computação de alto desempenho está crescendo. Estamos diversificando onde e como nós fonte de capacidade para que nossos clientes são isolados da variação da oferta.
** Nós adicionamos um segundo cluster de Docker Gen 2 para que as explosões de tráfego sejam distribuídas em dois clusters.** Também estamos adicionando alertas sobre a saturação do disco do servidor de agendamento e sobre a rapidez com que o programador coloca trabalhos, e um alerta que dispara quando um servidor começa sem seus discos rápidos em uso. Fizemos o script de configuração de disco falhar com um erro, e restauramos o envio de log desses servidores para que um problema semelhante seja visível mais cedo.
A experiência do cliente é nossa principal prioridade, e nos comprometemos a melhorar continuamente a confiabilidade de nossos sistemas para corresponder à confiança que nossos clientes depositam em nós. Agradecemos aos nossos clientes pela sua paciência enquanto a nossa equipa trabalhou para resolver estes incidentes. Por favor, contacte a nossa equipa de apoio com quaisquer perguntas ou preocupações.
Traduzido automaticamente da atualização oficial do incidente.
Atrasos no processamento de novas inscrições e mudanças de planos
Início 23 Gwengolo 2026 da 18:13 UTC · 1h 53m
Pending
Componentes afetados
Billing & Account
identified
Os clientes podem experimentar atrasos em novas inscrições e planejar mudanças sendo refletidas em sua conta.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Atrasa o início dos trabalhos da Linux Machine
Início 21 Gwengolo 2026 da 16:22 UTC · 47m
IssuesMinor incident
Componentes afetados
Machine Jobs
investigating
Os clientes podem ter atrasos em iniciar trabalhos na Linux Machine. Estamos a investigar.
monitoring
Tempos de espera da tarefa para o Linux Machine estão voltando ao normal.
resolved
This incident has been resolved.
Traduzido automaticamente da atualização oficial do incidente.
Clientes podem experimentar atrasos em atualizações de UI
Início 16 Gwengolo 2026 da 14:55 UTC · 4h 35m
IssuesMinor incident
Componentes afetados
CircleCI APICircleCI UI
investigating
Estamos a investigar um atraso na disponibilidade de dados do gasoduto. Os tubos ainda estão em execução, mas os dados sobre eles podem ser atrasados na interface ou API.
identified
Identificámos a questão e estamos a trabalhar numa reparação. Obrigado pela vossa paciência.
identified
Os dados da tubulação estão agora disponíveis como normais, com exceção dos resultados dos testes, que ainda podem ser atrasados. Continuamos a trabalhar nisto, obrigado pela vossa paciência.
monitoring
Todos os dados do gasoduto estão agora disponíveis como normal. Continuaremos a monitorizar a recuperação.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Clientes podem experimentar atrasos em atualizações de UI
Início 15 Gwengolo 2026 da 14:42 UTC · 2h 20m
IssuesMinor incident
Componentes afetados
CircleCI UI
investigating
Estamos a ver um atraso nos dados dos gasodutos na UI.
identified
Estamos a começar a ver alguma recuperação.
resolved
O incidente que afectou os dados do gasoduto na UI já foi resolvido. Agradecemos a sua paciência enquanto nossos engenheiros trabalharam na redução dos atrasos.
Traduzido automaticamente da atualização oficial do incidente.
Aumento dos tempos de espera para trabalhos macOS
Início 14 Gwengolo 2026 da 11:59 UTC · 1h 0m
IssuesMinor incident
Componentes afetados
macOS Jobs
investigating
Devido ao aumento de erros de rede e latências, estamos vendo tempos de espera aumentados para trabalhos macOS. Estamos investigando isso com o nosso provedor de hospedagem macOS.
investigating
Tempos de espera para trabalhos macOS estão reduzindo e estamos continuando a investigar.
monitoring
Nosso provedor de hospedagem macOS implementou uma mitigação e vimos latências melhoradas. Continuaremos a monitorizar.
resolved
As horas de espera para trabalhos macOS estão de volta ao normal.
Traduzido automaticamente da atualização oficial do incidente.
Questões de carregamento de gasodutos para um pequeno número de projectos
Início 10 Gwengolo 2026 da 20:25 UTC · 1m
IssuesMinor incident
Componentes afetados
CircleCI UI
identified
Um pequeno número de clientes pode ver erros ou não ser capaz de carregar a página pipelines para projetos com avisos de configuração desactualizados, ao usar a visão de pipelines clássica. Os clientes na nova vista gasodutos não são afetados. Identificamos a causa e colocamos uma solução.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido. Um pequeno número de clientes que criaram pipelines entre 18:53 UTC e 19:24 UTC que continha config usando sintaxe de configuração deprecada terá visto seus trabalhos de build-type falharem em iniciar. Os clientes cujos trabalhos ou oleodutos falharam podem repeti-los.
Traduzido automaticamente da atualização oficial do incidente.
atrasos de trabalho do macOS
Início 4 Gwengolo 2026 da 15:16 UTC · 1h 40m
IssuesMinor incident
Componentes afetados
macOS Jobs
investigating
Detectamos problemas de rede que afetam nossa infraestrutura Mac. Estamos a investigar e vamos fornecer actualizações em breve. Os clientes podem experimentar fila durante este tempo.
identified
Identificamos o problema de rede com nosso provedor de infraestrutura Mac, e estamos trabalhando com eles para resolver o problema. Estamos começando a ver alguma recuperação, mas esperamos que os clientes ainda possam ver algumas filas. Voltaremos a actualizar-nos em breve.
monitoring
Nosso provedor de infraestrutura Mac aplicou uma correção para este problema de rede e estamos vendo os tempos de fila retornarem ao normal. Vamos continuar a vigiar as coisas por mais algum tempo. Voltaremos a actualizar-nos em breve.
resolved
Não vimos mais impacto nos tempos de fila e tudo voltou ao normal. Agradecemos a sua paciência enquanto trabalhamos para resolver e monitorar esta questão.
Traduzido automaticamente da atualização oficial do incidente.
Erros intermitentes ao visualizar interfaces de uso de planos ou chamar APIs de uso de planos
Início 26 Eost 2026 da 15:43 UTC · 27m
IssuesMinor incident
Componentes afetados
CircleCI APICircleCI UI
identified
Os clientes podem experimentar erros intermitentes ao visualizar interfaces de uso de planos ou chamar APIs de uso de planos. Identificámos a questão e estamos a trabalhar activamente para atenuar estes erros.
monitoring
Amenizamos o problema com APIs de uso de planos e as páginas relevantes na UI estão carregando corretamente.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Interrupção do Login do GitHub
Início 25 Eost 2026 da 20:00 UTC · 0m
IssuesMinor incident
resolved
Entre 19:49 UTC e 21:07 UTC em 25 de agosto de 2026, os clientes que tentavam entrar no CircleCI usando o GitHub não conseguiram entrar, e receberam um erro do GitHub afirmando que a URL de retorno de chamadas era inválida. Os clientes que já estavam logados não foram afetados. O problema foi resolvido e o login do GitHub está funcionando normalmente. Agradecemos a sua paciência, enquanto nossa equipe trabalhou na implementação de uma correção.
Traduzido automaticamente da atualização oficial do incidente.
Os dados do Insight estão atualmente atrasados
Início 17 Eost 2026 da 21:06 UTC · 31m
IssuesMinor incident
Componentes afetados
CircleCI Insights
identified
A causa da questão foi identificada e estamos a resolvê-la.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Os dados do Insights são bons mais uma vez. Obrigado pela vossa paciência.
Traduzido automaticamente da atualização oficial do incidente.
