Nogle brugere kan se øgede ventetider for gen2 Docker job på grund af kapacitetsproblemer.
identified
Vi tilføjer yderligere kapacitet til at hjælpe med at mindske problemet. Bemærk: Vi ser stadig forsinkelser op til 20 minutter på 2xlarge.
identified
Afvent tider for 2xstore docker job er ved at komme sig. Vi vil fortsætte med at opdatere som kapacitet kommer online.
identified
Ventetider for 2xstore docker job er nu under 60 sekunder.
Ventetider for andre ressourcestørrelser blev ikke påvirket af denne hændelse og forbliver under 10 sekunder.
monitoring
Vi har set en fuld genopretning af ventetider for havnearbejde.
resolved
Ventetider for gen2 Docker job er kommet sig og job kører inden for normale ventetider.
postmortem
# # Summary
Fra 15: 44 til 20: 55 UTC den 21. oktober, kunder kører Gen 2 Docker job oplevede øgede ventetider for deres job til at starte. Forsinkelser var længst på 2xlarge ressource klasse, hvor job ventede op til 20 minutter. Hændelsen skyldtes begrænset tilgængelighed af de cloud-tilfælde, vi havde konfigureret til at imødekomme efterspørgslen, især for 2xstore job.
Som svar, vores ingeniør team konfigureret yderligere instans typer, konfigureret yderligere Gen 2 Docker klynger. Ved 20: 55 UTC, ventetider var vendt tilbage til normal og hændelsen blev løst.
Efter hændelsen blev løst, udvidede vi vores Gen 2 Docker flåde til yderligere skyregioner, og vi fortsætter aktivt med at stå op yderligere skyregioner for at forhindre lignende hændelser i fremtiden.
Den oprindelige status side kan findes her: [Oktober 21 - Øget Docker gen2 ventetider] (https: / / status.circleci.com / hændelser / 5jb50gh55gtj).
# Baggrund
Når CircleCI udfører et Docker job, vi planlægge det på en af flere klynger af cloud tilfælde, og hver instans er i stand til at udføre flere isolerede job. At planlægge et job på en cloud-instans er en klassiker ["bin packing problem"] (https: / / en.wikipedia.org / wiki / Bin _ packing _ problem): at finde ledig kapacitet, der passer til den ønskede ressourceklasse 'CPU, hukommelse og opbevaring. Større ressource klasser som 2xlarge er sværere at passe end mindre dem, som pakkes sammen mere stramt.
Vi leverer cloud-instanser ved hjælp af en rangeret liste over eksempler typer. Hvis skyen udbyder ikke kan levere vores første valg, vi falder tilbage til den næste type på listen. Vi fastholder endvidere en minimumsstørrelse på flåden: et minimum af tilfælde forbliver i drift, så vi ikke opgiver kapaciteten, når efterspørgslen er lav. Over dette minimum af flådestørrelse tilføjer vi eksempler, efterhånden som efterspørgslen stiger.
Når der ikke er tilstrækkelig kapacitet til at udføre en arbejdsbyrde, køler vi arbejdet, indtil kapaciteten bliver tilgængelig.
Hvad skete der
_\ (Alle gange UTC\)
Fra kl. 15: 44 den 21. oktober steg efterspørgslen efter Gen 2 2xstore ressourceklasse kraftigt, og vi leverede ikke ekstra kapacitet hurtigt nok til at holde trit. Vores ingeniørhold begyndte at undersøge. Ved 19: 25, ventetider for Gen 2 2xlarge ressource klasse havde nået 20 minutter, og ventetider for andre ressourcer klasser var steget så godt.
Ved 19: 56 havde vores ingeniørhold konfigureret yderligere eksempler typer til Gen 2 flåde for at få mere kapacitet online, og ved 19: 59, vi var at levere disse tilfælde typer. Kl. 20: 11 tilføjede vi flere yderligere Gen 2-klynger og øgede den minimale flådestørrelse på disse klynger.
Ved 20: 35 vendte antallet af job i kø tilbage til det normale niveau, og ved 20: 41 begyndte 95% af 2xstore job på 4 sekunder. Vi løste hændelsen kl. 20.55.
Efter at have løst denne hændelse, vi tilføjet yderligere cloud-regioner til Docker job til at stille mere kapacitet til rådighed.
# Fremtidig forebyggelse og procesforbedring
Vi har allerede taget følgende skridt til at forbedre starttiderne for job, herunder sourcing af kapacitet fra flere steder, reservere mere kapacitet til store ressourceklasser og gennemføre hurtigere levering.
* * Vi har tilføjet yderligere regioner til Docker job. * * Vi har for nylig tilføjet yderligere skyregioner til Machine job, og vi har nu gjort det samme for Docker job.
* * Vi vil aktivt fortsætte med at tilføje yderligere cloud regioner for både Docker og Machine job * *.
* * Vi har tilføjet yderligere Gen 2 klynger * *. Vi konfigurerede flere yderligere Gen 2 klynger til at planlægge job hurtigere, og til at gøre mere samlet kapacitet til rådighed.
* * Vi har udvidet det sæt af cloud instance typer vi bruger og har hævet vores minimum flåde størrelse. * * Vi har konfigureret yderligere eksempler typer. Vi har også øget flådens minimumsstørrelse for Gen 2 for at imødekomme den aktuelle efterspørgsel.
* * Vi har ændret vores jobscheduler til at prioritere planlægning af større ressourceklasser. * * Vi har ændret vores tidsplan for job for at balancere ventetider mere retfærdigt på tværs af ressourceklasser, og for at kombinere job mere effektivt på tilgængelige tilfælde.
# # Konklusion
Kundeoplevelsen er vores topprioritet, og vi forpligter os til løbende at forbedre pålideligheden af vores systemer til at matche den tillid, som vores kunder lægger i os. Vi takker vores kunder for deres tålmodighed, mens vores team arbejdede for at løse denne hændelse.
Kontakt vores supporthold med spørgsmål eller bekymringer.
Automatisk oversat fra den officielle hændelsesopdatering.
Øget ventetid for macOS job på m4pro.large
Startede 20. oktober 2026 kl. 15.58 UTC · 2h 16m
IssuesMindre hændelse
Berørte komponenter
macOS Jobs
investigating
Vi ser øgede ventetider for nogle macOS job ved hjælp af m4pro.large ressource klasse. Vi efterforsker og vil snart opdatere igen. Tak for din tålmodighed.
monitoring
Kunder kører macOS job på m4pro.large ressource klasse er stadig ser øgede ventetider, med nogle job venter op til 30 minutter til at starte. Vi fortsætter med at overvåge dette og vil dele en anden opdatering snart.
monitoring
Vente tider for m4pro.large er stadig forhøjet på grund af tung stor efterspørgsel. Alle m4pro.medium er normale. Vi overvåger aktivt, vi sætter pris på tålmodighed.
monitoring
Ventetider for macOS job på m4pro.large ressource klasse er ved at komme sig. Jobs ved hjælp af Xcode 27.0 venter nu omkring ~ 3,5 minutter i gennemsnit, ned fra omkring ~ 40 minutter på toppen. Jobs med Xcode 26.6 og 26.4.1 arbejder stadig gennem en efterslæb, som er clearing. Ventetider på m4pro.medium er normale. Vi vil dele endnu en opdatering, så snart vi fortsætter med at overvåge.
resolved
Ventetider for macOS job på m4pro.large ressource klasse er vendt tilbage til normal. Vi takker dig for din tålmodighed, mens backlogs ryddet.
Automatisk oversat fra den officielle hændelsesopdatering.
Forsinkelser starter macOS job, der bruger Xcode 26.6.0
Startede 14. oktober 2026 kl. 14.47 UTC · 1h 13m
IssuesMindre hændelse
Berørte komponenter
macOS Jobs
investigating
Da omkring 14: 00 UTC, kunder kører macOS job, der bruger Xcode 26.6.0 på M4 Pro store ressource klasse oplever forsinkelser starter job. Ventetider har nået 30 minutter eller mere.
Tak for din tålmodighed, mens vores ingeniører undersøge. Vi vil levere endnu en opdatering inden 15: 30 UTC.
identified
Forsinkelser starter macOS job, der bruger XCode 26.6.0 er kommet sig. Da ca. 15: 11 UTC, macOS job, der bruger XCode 26.4 oplever forsinkelser starter, med ventetider på omkring 30 minutter.
Tak for Deres tålmodighed, mens vores ingeniører arbejder på at løse dette. Vi vil levere endnu en opdatering inden 15: 45 UTC.
resolved
Mellem ca. 14: 00 UTC og 15: 51 UTC den 14. oktober, kunder kører macOS job, der bruger Xcode 26.6.0 eller Xcode 26.4 oplevede forsinkelser starter job. Fra ca. 14: 00 UTC, job, der bruger Xcode 26.6.0 på M4 Pro store ressource klasse ventede 30 minutter eller mere til at starte, og disse forsinkelser inddrives på ca. 15: 12 UTC. Fra omkring 15: 11 UTC, job, der bruger Xcode 26.4 ventede omkring 30 minutter til at starte.
Problemet er løst, og alle berørte funktioner er vendt tilbage til normal. Vi takker dig for din tålmodighed, mens vores team arbejdede på at gennemføre et fix.
Automatisk oversat fra den officielle hændelsesopdatering.
Forsinkelse i data vises i UI og API
Startede 9. oktober 2026 kl. 11.33 UTC · 14h 36m
OutageStørre hændelse
Berørte komponenter
CircleCI APICircleCI UI
identified
Der er en forsinkelse i vores datainfrastruktur forårsager forsinkelser før bygge data og nogle meddelelser bliver synlige. Vi arbejder på en afbødning.
identified
Hvad er påvirket:
Kunder udløser rørledninger, og kunder, der er afhængige af udgående webkroge og e-mail og Slack meddelelser.
Hvad kan du forvente
Siden 11: 15 UTC:
- Rørledninger er stadig ved at blive oprettet, mens dette er i gang, men endnu ikke behandlet, så hentning kan resultere i duplikerede rørledninger.
- Udgående webkroge og transaktionsmeddelelser (Slack og e-mail) bliver ikke sendt.
- Pipeline-status er måske ikke synlig.
- Brug opladning data på Project Usage side vil være gamle.
Tak for Deres tålmodighed, mens vores ingeniører arbejder på at løse dette.
Næste opdatering:
Vi vil give endnu en opdatering inden 13: 30 UTC.
identified
Mellem 11: 15 UTC og omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og transaktionsmeddelelser (Slack og e-mail) blev ikke sendt.
Hvad er påvirket:
Kunder udløser rørledninger, og kunder, der er afhængige af udgående webkroge og e-mail og Slack meddelelser.
Hvad kan du forvente:
- Siden omkring 13: 00 UTC, er rørledninger under behandling igen og job er begyndt.
- De fleste job starter i øjeblikket inden for omkring 4 minutter, og nogle venter op til omkring 10 minutter. Rørledninger udløst under hændelsen er stadig under behandling og kan tage længere tid at starte.
- Udgående webkroge og meddelelser er genoptaget.
- Rørledninger er stadig ved at blive behandlet fra backlog, så hentning kan resultere i duplikerede rørledninger.
Tak for Deres tålmodighed, mens vores ingeniører arbejder på at løse dette.
Næste opdatering:
Vi vil levere endnu en opdatering kl 14: 00 UTC.
identified
Siden 11: 15 UTC, kunder har oplevet forstyrrelser af rørledninger og meddelelser. Mellem 11: 15 UTC og omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og transaktionsmeddelelser (Slack og e-mail) blev ikke sendt.
Hvad er påvirket
Kunder, der kører arbejdsgange og job, og kunder, der ser brugsdata på projektanvendelsessiden.
Hvad kan du forvente
- Pipelines er under behandling igen, herunder dem, der udløses under hændelsen.
- Siden omkring 13: 25 UTC, har arbejdsgange og job været begyndt med stigende forsinkelser, mens vi arbejder gennem efterslæbet. De fleste job starter i øjeblikket inden for omkring 10 minutter, og nogle venter op til omkring 25 minutter.
- Vi regner med at gennemgå dette efterslæb omkring 14: 35 UTC.
- Arbejdsgange fra rørledninger udløst under hændelsen venter stadig på at starte, så hentning kan resultere i duplikerede arbejdsgange.
- Brug opladning data på Project Usage side er i øjeblikket gamle.
Tak for Deres tålmodighed, mens vores ingeniører arbejder på at løse dette.
Næste opdatering
Vi vil levere endnu en opdatering inden 14: 30 UTC.
identified
Siden 11: 15 UTC, kunder har oplevet forstyrrelser af rørledninger og meddelelser. Mellem 11: 15 UTC og omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og transaktionsmeddelelser (Slack og e-mail) blev ikke sendt.
Hvad er påvirket
Kunder, der kører arbejdsgange og job, og kunder, der ser brugsdata på projektanvendelsessiden.
Hvad kan du forvente
- Forsinkelser i arbejdets start og i jobbene forbedres. De fleste job starter nu inden for omkring 3 minutter, ned fra omkring 10 minutter på 13: 50 UTC.
- Nogle arbejdsgange fra rørledninger udløst under hændelsen venter stadig på at starte op til omkring 40 minutter.
- Det tager lidt længere tid end forventet at arbejde med efterslæbet. Vi forventer nu at rydde det ved omkring 14: 45 UTC.
- Arbejdsgange fra rørledninger udløst under hændelsen venter stadig på at starte, så hentning kan resultere i duplikerede arbejdsgange.
- Brug opladning data på Project Usage side er i øjeblikket gamle.
Tak for Deres tålmodighed, mens vores ingeniører arbejder på at løse dette.
Næste opdatering
Vi vil give endnu en opdatering inden 15: 00 UTC.
identified
Siden 11: 15 UTC, kunder har oplevet forstyrrelser af rørledninger og meddelelser. Mellem 11: 15 UTC og omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og transaktionsmeddelelser (Slack og e-mail) blev ikke sendt. Mellem ca. 13: 00 UTC og 14: 40 UTC begyndte arbejdsgange og job med forsinkelser, mens vi arbejdede med efterslæbet.
Hvad er påvirket
Kunder, der kører arbejdsgange og job, og kunder, der ser brugsdata på projektanvendelsessiden.
Hvad kan du forvente
- Tilbagekaldelsen af arbejdsgange fra rørledninger udløst under hændelsen ryddet omkring 14: 40 UTC.
- De fleste job starter nu inden for 30 sekunder, og nogle venter på op til omkring 3 minutter.
- Brug opladning data på Project Usage side er i øjeblikket gamle.
Tak for din tålmodighed, mens vores ingeniører fortsætte med at arbejde på det underliggende spørgsmål.
Næste opdatering
Vi vil levere endnu en opdatering inden 15: 10 UTC.
monitoring
Siden 11: 15 UTC, kunder har oplevet forstyrrelser af rørledninger og meddelelser. Mellem 11: 15 UTC og omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og transaktionsmeddelelser (Slack og e-mail) blev ikke sendt. Mellem ca. 13: 00 UTC og 14: 40 UTC begyndte arbejdsgange og job med forsinkelser, mens vi arbejdede med efterslæbet.
Hvad er påvirket
Kunder, der kører arbejdsgange og job, og kunder, der ser brugsdata på projektanvendelsessiden.
Hvad kan du forvente
- Efterslæbet af rørledninger og arbejdsgange fra hændelsen er ryddet.
- Siden omkring 14: 45 UTC, de fleste arbejdsgange og job starter inden for omkring 15 sekunder, og starttiderne fortsætter med at vende tilbage til normal.
- Brug opladning data på Project Usage side er i øjeblikket gamle.
Tak for din tålmodighed, mens vores ingeniører overvåge opsvinget.
Næste opdatering
Vi vil levere endnu en opdatering inden 15: 20 UTC.
monitoring
Siden 11: 15 UTC, kunder har oplevet forstyrrelser af rørledninger og meddelelser. Mellem 11: 15 UTC og omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og transaktionsmeddelelser (Slack og e-mail) blev ikke sendt. Mellem ca. 13: 00 UTC og 14: 40 UTC begyndte arbejdsgange og job med forsinkelser, mens vi arbejdede med efterslæbet.
Hvad er påvirket
Kunder, der ser rørledninger, arbejdsgange og job i CircleCI UI, og kunder, der ser brugsdata på projektanvendelsessiden.
Hvad kan du forvente
- Arbejdsgange og job kører til tiden.
- CircleCI UI er cirka 30 minutter bagud. Nye arbejdsgange og statusændringer kan tage så lang tid at komme frem.
- Vores ingeniører arbejder aktivt på at fremskynde behandlingen, så UI kan indhente det forsømte.
- Undgå at hente arbejdsgange, der endnu ikke vises i UI, da dette kan skabe duplikater.
- Brug opladning data på Project Usage side er i øjeblikket gamle.
Tak for din tålmodighed, mens vores ingeniører arbejder på at reducere denne forsinkelse.
Næste opdatering
Vi vil levere endnu en opdatering kl 16: 00 UTC.
monitoring
Siden 11: 15 UTC, kunder har oplevet forstyrrelser af rørledninger og meddelelser. Mellem 11: 15 UTC og omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og transaktionsmeddelelser (Slack og e-mail) blev ikke sendt. Mellem ca. 13: 00 UTC og 14: 40 UTC begyndte arbejdsgange og job med forsinkelser, mens vi arbejdede med efterslæbet.
Hvad er påvirket
Kunder, der kører arbejdsgange og job, kunder, der ser rørledninger, arbejdsgange og job i CircleCI UI, og kunder, der ser brugsdata på projektanvendelsessiden.
Hvad kan du forvente
- Siden omkring 15: 15 UTC har arbejdsgange og job været begyndt med stigende forsinkelser. De fleste job starter i øjeblikket inden for omkring 4 minutter, og nogle venter op til omkring 20 minutter.
- CircleCI UI forbliver omkring 30 minutter bagud i gennemsnit, og nogle opdateringer tager længere tid. Nye arbejdsgange og statusændringer kan tage så lang tid at komme frem.
- Undgå at hente arbejdsgange, der endnu ikke vises i UI, da dette kan skabe duplikater.
- Brug opladning data på Project Usage side er i øjeblikket gamle.
Tak for din tålmodighed, mens vores ingeniører arbejder på at reducere disse forsinkelser.
Næste opdatering
Vi vil levere endnu en opdatering kl 16: 30 UTC.
monitoring
Siden 11: 15 UTC, kunder har oplevet forstyrrelser af rørledninger og meddelelser. Mellem 11: 15 UTC og omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og transaktionsmeddelelser (Slack og e-mail) blev ikke sendt. Mellem ca. 13: 00 UTC og 14: 40 UTC begyndte arbejdsgange og job med forsinkelser, mens vi arbejdede med efterslæbet. Siden ca. 15: 15 UTC har arbejdsgange og job igen været begyndt med forsinkelser.
Hvad er påvirket
Kunder, der kører arbejdsgange og job, kunder, der ser rørledninger, arbejdsgange og job i CircleCI UI, og kunder, der ser brugsdata på projektanvendelsessiden.
Hvad kan du forvente
- Forsinkelser, der starter arbejdsgange og job er stoppet med at stige og er begyndt at lette. De fleste job starter inden for omkring 4 minutter, og nogle venter op til omkring 25 minutter.
- CircleCI UI er nu omkring 20 minutter bagud, ned fra omkring 30 minutter. Nye arbejdsgange og statusændringer kan tage så lang tid at komme frem.
- Undgå at hente arbejdsgange, der endnu ikke vises i UI, da dette kan skabe duplikater.
- Brug opladning data på Project Usage side er i øjeblikket gamle.
Tak for din tålmodighed, mens vores ingeniører arbejder på at reducere disse forsinkelser.
Næste opdatering
Vi vil give endnu en opdatering inden 17: 00 UTC.
monitoring
Siden 11: 15 UTC, kunder har oplevet forstyrrelser af rørledninger og meddelelser. Mellem 11: 15 UTC og omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og transaktionsmeddelelser (Slack og e-mail) blev ikke sendt. Mellem ca. 13: 00 UTC og 14: 40 UTC begyndte arbejdsgange og job med forsinkelser, mens vi arbejdede med efterslæbet. Siden ca. 15: 15 UTC har arbejdsgange og job igen været begyndt med forsinkelser.
Hvad er påvirket
Kunder, der kører arbejdsgange og job, kunder, der ser rørledninger, arbejdsgange og job i CircleCI UI, og kunder, der ser brugsdata på projektanvendelsessiden.
Hvad kan du forvente
- Forsinkelser, der starter arbejdsgange og job, holder konstant. De fleste job starter inden for omkring 4 minutter, og nogle venter op til omkring 8 minutter, ned fra omkring 25 minutter.
- CircleCI UI er 20 minutter bagud i gennemsnit, og nogle opdateringer tager længere tid. Nye arbejdsgange og statusændringer kan tage så lang tid at komme frem.
- Undgå at hente arbejdsgange, der endnu ikke vises i UI, da dette kan skabe duplikater.
- Brug opladning data på Project Usage side er i øjeblikket gamle.
Tak for din tålmodighed, mens vores ingeniører arbejder på at reducere disse forsinkelser.
Næste opdatering
Vi vil levere endnu en opdatering kl 17: 30 UTC.
identified
Siden 11: 15 UTC, kunder har oplevet forstyrrelser af rørledninger og meddelelser. Mellem 11: 15 UTC og omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og transaktionsmeddelelser (Slack og e-mail) blev ikke sendt. Mellem ca. 13: 00 UTC og 14: 40 UTC begyndte arbejdsgange og job med forsinkelser, mens vi arbejdede med efterslæbet. Siden ca. 15: 15 UTC har arbejdsgange og job igen været begyndt med forsinkelser.
Hvad er påvirket
Kunder, der udløser rørledninger og løbende arbejdsgange og job, kunder, der ser rørledninger, arbejdsgange og job i CircleCI UI, og kunder, der ser brugsdata på projektanvendelsessiden.
Hvad kan du forvente
- Siden omkring kl. 17: 00 UTC er forsinkelserne steget betydeligt. De fleste job tager nu omkring 12 minutter at starte, og nogle venter op til omkring 30 minutter.
- Siden omkring 17: 15 UTC, er nogle job ikke at starte.
- Rørledninger behandles langsommere, så nogle kan tage længere tid at starte.
- CircleCI UI er mere end en time bagud. Nye arbejdsgange og statusændringer kan tage så lang tid at komme frem.
- Undgå at hente arbejdsgange, der endnu ikke vises i UI, da dette kan skabe duplikater.
- Brug opladning data på Project Usage side er i øjeblikket gamle.
Tak for Deres tålmodighed, mens vores ingeniører arbejder på at løse dette.
Næste opdatering
Vi vil levere endnu en opdatering kl 18: 00 UTC.
identified
Siden 11: 15 UTC, kunder har oplevet forstyrrelser af rørledninger og meddelelser. Mellem 11: 15 UTC og omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og transaktionsmeddelelser (Slack og e-mail) blev ikke sendt. Mellem ca. 13: 00 UTC og 14: 40 UTC begyndte arbejdsgange og job med forsinkelser, mens vi arbejdede med efterslæbet. Siden ca. 15: 15 UTC har arbejdsgange og job igen været begyndt med forsinkelser.
Hvad er påvirket
Kunder, der udløser rørledninger og løbende arbejdsgange og job, kunder, der ser rørledninger, arbejdsgange og job i CircleCI UI, og kunder, der ser brugsdata på projektanvendelsessiden.
Hvad kan man forvente
- Siden omkring 17: 00 UTC, vi ser en stigning i forsinkelser. De fleste job tager nu omkring 25 minutter at starte, og nogle venter på op til omkring en time.
- Siden ca. 17: 15 UTC er nogle arbejdsgange inden for fremskridt mislykkedes, og et lille antal job er ikke i gang.
- Nye rørledninger er i kø og tager længere tid at starte.
- CircleCI UI er mere end en time bagud. Nye arbejdsgange og statusændringer kan tage så lang tid at komme frem.
- Undgå at hente arbejdsgange, der endnu ikke vises i UI, da dette kan skabe duplikater.
- Brug opladning data på Project Usage side er i øjeblikket gamle.
Vores ingeniører arbejder fortsat på at løse problemet.
Næste opdatering
Vi leverer endnu en opdatering kl. 18.30 UTC.
identified
Hvad er ændret siden vores seneste opdatering
* CircleCI UI er omkring en time bagud, og op til omkring 90 minutter for nogle opdateringer. Arbejdsgange og job kan allerede have kørt eller være i gang, selv om EU-erhvervsgrenen viser dem, at de ikke er startet eller slet ikke viser dem.
* Jobs, der kører er begyndt hurtigere. De fleste starter nu inden for omkring 15 minutter, ned fra omkring 28 minutter, selvom nogle stadig venter over en time.
* Nye rørledninger forsinkes i stigende grad.
* Nogle arbejdsgange svigter stadig. Arbejdsgange, der ikke kunne behandles i tide, markeres som mislykkede.
* Undgå at hente arbejdsgange, der endnu ikke vises i UI, da dette kan skabe duplikater.
Stadig igangværende:
Brug opladning data på Project Usage side er gamle.
Næste opdatering
Vi vil levere endnu en opdatering kl 19: 00 UTC.
identified
Hvad er ændret siden vores seneste opdatering
* Jobs starter hurtigere. De fleste starter nu inden for omkring 8 minutter, ned fra omkring 15 minutter, og de længste ventetider er faldet fra over en time til omkring 45 minutter.
* CircleCI UI er begyndt at indhente, men det er stadig bagud. Arbejdsgange og job kan allerede have kørt eller være i gang, selv om EU-erhvervsgrenen viser dem, at de ikke er startet eller slet ikke viser dem.
* Rørledninger behandles hurtigere, men nye rørledninger forsinkes stadig.
Stadig igangværende
* Nogle arbejdsgange og job svigter stadig.
* Undgå at hente arbejdsgange, der endnu ikke vises i UI, da dette kan skabe duplikater.
* Brug opladning data på Project Usage side er gamle.
Næste opdatering
Vi vil levere endnu en opdatering kl 19: 30 UTC.
identified
Siden vores seneste opdatering, starter job hurtigere: de fleste starter nu inden for omkring 6 minutter, ned fra omkring 8 minutter. CircleCI UI er ved at indhente, men stadig omkring en time bagud. Nye rørledninger behandles, efterhånden som de ankommer.
Jobs kan allerede have kørt, selv om UI ikke viser dem endnu, så undgå at hente arbejdsgange, der ikke vises i UI.
Vi vil levere endnu en opdatering kl 20: 00 UTC.
identified
Jobs starter hurtigere og færre mislykkes: de fleste job starter nu inden for omkring 4 minutter, ned fra omkring 6 minutter, og de længste ventetider er faldet fra omkring 30 minutter til omkring 20 minutter.
Der arbejdes nu på rørledninger fra tidligere i hændelsen.
CircleCI UI er stadig bagud, og nogle ældre opdateringer kan tage længere tid at vise sig. Jobs kan allerede have kørt, selv om UI ikke viser dem endnu, så undgå at hente arbejdsgange, der ikke vises i UI.
Vi vil levere endnu en opdatering kl 20: 30 UTC.
identified
Siden omkring 20: 48 UTC er nye arbejdsgange og job ikke begyndt. Vi har midlertidigt pause starte nyt arbejde, så vores systemer kan indhente det arbejde, der allerede er i gang, herunder forsinkede opdateringer til CircleCI UI og API. Ældre opdateringer er nu vises i UI og API som denne efterslæb rydder. Nye rørledninger bliver stadig accepteret og i kø
Undgå at hente rørledninger eller arbejdsgange i løbet af denne tid, da dette kan skabe duplikater, når arbejdet genoptages.
Vi vil give endnu en opdatering inden 22: 00 UTC.
identified
Siden vores seneste opdatering, er de fleste af de rørledninger, der blev forsinket tidligere i hændelsen nu blevet behandlet, og deres arbejdsgange er i kø til at starte. Nye arbejdsgange og job er stadig sat på pause, mens vi forbereder os på at genoptage arbejdet sikkert. Forsinkede opdateringer fortsat vises i CircleCI UI og API.
Fortsæt med at undgå at hente rørledninger eller arbejdsgange, da dette kan skabe duplikater, når arbejdet genoptages.
Vi vil give en anden opdatering af 22: 30 UTC.
identified
Siden vores seneste opdatering er vi begyndt gradvist at genoptage arbejdet, og nogle arbejdsgange i kø og job begynder igen. Det meste arbejde i kø venter stadig, og job, der starter, kan have ventet over en time. Vi øger hastigheden omhyggeligt for at undgå overbelastning af vores systemer. Forsinkede opdateringer fortsat vises i CircleCI UI og API.
Forsæt venligst med at undgå at hente rørledninger eller arbejdsgange, da dette kan skabe duplikater som i kø arbejde genoptager.
Vi vil give endnu en opdatering inden 23: 00 UTC.
identified
Et stort antal queued workflows og job er startet, og CircleCI UI og API har indhentet og viser opdateringer normalt med få forsinkelser. Vi arbejder fortsat med det resterende arbejde i køen. Jobs fra køen kan have ventet omkring en time eller mere til at starte, og nogle Linux job venter op til omkring 10 minutter for kapacitet.
Fortsæt venligst med at undgå hentning, mens arbejde i køen fortsætter med at bearbejde.
Vi vil levere endnu en opdatering kl 23: 30 UTC.
identified
Vi arbejder stadig med en betydelig efterslæb af arbejdsgange i kø og arbejdspladser. Ventetiderne forbedres, men de er længere end normalt, og nogle job har ventet over en time. CircleCI UI og API er fortsat opdateret. Undgå at hente rørledninger eller arbejdsgange, mens backlog rydder, da dette kan skabe duplikater. Vi vil give endnu en opdatering kl 00: 00 UTC.
identified
Siden vores seneste opdatering, har efterslæbet af queued arbejdsgange og job ryddet, fra omkring 23: 47 UTC. Arbejdsgange og job starter nu inden for få sekunder, og CircleCI UI og API er opdateret. Vi overvåger vores systemer nøje for at sikre, at de forbliver stabile. Vi vil levere endnu en opdatering kl. 00: 30 UTC.
identified
Arbejdsgange og job er fortsat med at starte normalt, inden for få sekunder, og CircleCI UI og API forbliver up to date. Slack og e-mail meddelelser forsinket tidligere i hændelsen stadig bliver leveret.
Brug opladning data på Project Usage side er gamle.
Vi fortsætter med at overvåge vores systemer nøje og vil give endnu en opdatering inden 01: 15 UTC.
monitoring
Arbejdsgange og job starter og kører normalt, og CircleCI UI og API er opdateret. Vi overvåger fortsat vores systemer nøje for at sikre, at de forbliver stabile.
Vi vil give endnu en opdatering inden 02: 00 UTC.
resolved
Mellem 11: 15 UTC og 23: 47 UTC den 9. oktober oplevede kunderne forsinkelser og svigt på tværs af rørledninger, arbejdsgange og arbejdspladser samt forsinkelser i CircleCI UI, API og meddelelser.
Fra 11: 15 til omkring 13: 00 UTC, rørledninger blev skabt, men ikke behandlet, og udgående webkroge og Slack og e-mail meddelelser blev ikke sendt. Fra omkring 13: 00 til 14: 40 UTC, arbejdsgange og job startede med forsinkelser, mens vi arbejdede gennem backloggen.
Fra omkring 15: 15 til 20: 48 UTC, arbejdsgange og job startede med stigende forsinkelser, på op til omkring en time, og CircleCI UI og API faldt bagud med op til omkring 2 timer. I løbet af denne periode, nogle job mislykkedes at starte og nogle i-fremskridt arbejdsgange mislykkedes.
Fra 20: 48 til omkring 22: 10 UTC, vi midlertidigt pause starter nye arbejdsgange og job, så vores systemer kunne komme sig. Nye rørledninger blev accepteret og i kø i denne periode. Fra omkring 22: 10 til 23: 47 UTC, i kø arbejdsgange og job genoptaget og blev behandlet. Nogle af dem havde ventet op til omkring 2 timer.
Problemet er løst, og alle berørte funktioner er vendt tilbage til normal. Brug opladning data på Project Usage side er endnu ikke opdateret og vil blive opdateret, når vores data backpails færdig. Kunder hvis job mislykkedes under dette vindue kan køre de berørte job igen. Vi takker dig for din tålmodighed, mens vores ingeniører arbejdede på at gennemføre en rettelse.
postmortem
# # Summary
Mellem 11: 15 UTC og 23: 47 UTC den 9. oktober oplevede CircleCI kunder lange forsinkelser og svigt på tværs af rørledninger, arbejdsgange og job, samt forsinkelser i CircleCI UI, API og meddelelser.
* Fra 11: 15 til 13: 00 UTC, rørledninger blev oprettet, men ikke behandlet, og udgående webkroge og Slack og e-mail meddelelser blev ikke sendt.
* Fra 13: 00 til 14: 40 UTC, arbejdsgange og job startede med forsinkelser, mens vi arbejdede gennem backlog.
* Fra 15: 15 til 20: 48 UTC, arbejdsgange og job startede med stigende forsinkelser, på op til omkring en time, og CircleCI UI og API faldt bagud med op til omkring 2 timer. I løbet af denne periode, nogle job mislykkedes at starte og nogle i-fremskridt arbejdsgange mislykkedes.
* Fra 20: 48 til 22: 10 UTC, vi midlertidigt pause starter nye arbejdsgange og job, så vores systemer kunne komme sig. Nye rørledninger blev accepteret og i kø i denne periode.
* Fra 22: 10 til 23: 47 UTC, i kø arbejdsgange og job genoptaget og blev behandlet med succes. Nogle af dem havde ventet op til omkring 2 timer.
* Ved 23: 47, hændelsen blev afbødet.
Den aktuelle side for denne hændelse kan findes på [9 oktober - Forsinkelse i data, der vises i UI og API] (https: / / status.circleci.com / hændelser / 6cfhlr4rmm0). EU-erhvervsgrenens økonomiske situation
Flere CircleCI-tjenester bruger Temporal bakkes op af Postgres som en pålidelig queuing mekanisme, og begge hændelser havde den samme årsag: hastigheden af skriver til Temporal 's Postgres instans var hurtigere end Postgres' s transaktionsjournal kunne arkivere disse skriver. I begge tilfælde medførte dette forsinkelser på flere timer i behandlingen af både rørledninger og statusmeddelelser.
Vi evaluerede flere afbødninger, hvorefter pausede nye workflow starter, så systemet kunne komme sig sikkert, og ramped tilbage gradvist. Så fik vi arbejdet op igen, indtil vores systemer blev normale igen.
For permanent at løse flaskehalsen, vi har delt arbejde på tværs af flere temporale tilfælde, hver med sin egen uafhængige database og arbejdstager klynger, og vi load- balance på tværs af dem. Vi havde allerede planlagt infrastrukturarbejde fra den 12. oktober, som ville have fjernet denne flaskehals og forhindret disse hændelser. Så starter 19: 11 den 9. oktober vores ingeniørhold implementeret, testet og rullet ud en enklere version af disse ændringer inden for et par timer. Vi tilføjede yderligere ny alarmering og afstemte de underliggende databaser for bedre ydeevne under høj belastning.
Kunder hvis job mislykkedes under dette vindue kan køre dem igen.
# Baggrund
For at køre kundejob udfører CircleCI en række trin: vi accepterer kunderørledninger; vi tildeler arbejdspladser til disse rørledninger til arbejdstagere; vi leverer statusopdateringer til disse rørledninger og job; og vi opkræver kunder for de kreditter, disse job forbruger. Hvert af disse trin gennemføres af en uafhængig tjeneste med pålidelige køer imellem.
Historisk har vi gennemført disse pålidelige køer med RabbitMQ på toppen af holdbar opbevaring, med eksponentiel backoff og døde bogstaver køer for pålidelighed. I løbet af det seneste år har vi i stigende grad genimplementeret vores pålidelige køer på [Temporal] (https: / / temporal.io /), som giver langt bedre holdbarhed og pålidelighed garantier over en enklere og mere kraftfuld programmeringsmodel. Vores build service\ (som gør en rørledning config til en eksekverbar plan\), vores workflow orkestrator service\ (som distribuerer opgaver på arbejdere\), vores notifikationstjeneste\ (som leverer statusopdateringer\), og vores opladning service\ (som opkræver kunder for kreditter\) alle nu bruge Temporal.
Temporal gemmer staten for sine arbejdsgange og aktiviteter\ (kaldet "historie"\) i en database, og dette er den eneste komponent i en temporal instans, der er synkron og stateful. Som følge heraf er en temporal instans evne til at acceptere og udføre workflows afhængig af skrivehastigheden i sin baggrunds database. Vi har også konfigureret Temporal til at slette afsluttede arbejdsgange og aktiviteter fra sin historie 3 dage efter de er afsluttet.
På tidspunktet for denne hændelse brugte vi en enkelt samlet temporal instans bakket op af en Multi- AZ Postgres RDS instans for alle disse pålidelige køer. Mens en Multi- AZ RDS instans er modstandsdygtig over for zonefejl, det opretholder database konsistens via en enkelt skrift-ahead- log\ (WAL\). På det tidspunkt havde vi konfigureret vores Postgres instans til at gemme sin WAL på en Dedikeret Log Volume\ (DLV\), så log skriver ikke konkurrere med data skriver. Databasen arkiverer loggen kontinuerligt til backup opbevaring, og den kan kun genbruge plads på lydstyrken efter loggen er blevet arkiveret. Hvis databasen skriver logs hurtigere end det arkiver, lydstyrken fylder og Postgres har ingen plads til at skrive sin WAL log. Så databasen stopper acceptere indgående skriver og går helt read- kun. En RDS DLV er begrænset til 1TB opbevaring og 3000 IOPS og pr AWS disse grænser er hardcodet og kan ikke øges.
Hvad skete der
_\ (Alle gange UTC\)
En af de faktorer, der bidrog til den 6. oktober, var, at vi var ved at behandle en høj sats af temporal historie sletninger på samme tid som indgående arbejde, hvilket igen lægge pres på backing database. For at løse den 6. oktober, ændrede vi oprydning indstillinger på Temporal 's største tabeller og flyttede transaktionsloggen tilbage til sin dedikerede volumen. Disse ændringer elimineret den vigtigste kilde til transaktion log skriver, men ikke overveje den yderligere log skriver fra planlagte sletninger. Fordi vi har konfigureret Temporal til at slette afsluttede arbejdsgange og aktiviteter fra sin historie 3 dage efter de er afsluttet, den 6. oktober historie var planlagt til at blive slettet den 9. oktober.
Startende på 08: 00 den 9. oktober, Temporal begyndte at behandle disse planlagte sletninger, og som en konsekvens ledig plads på Postgres DLV begyndte at falde brat, fra 0.8TB ved 08: 00 til 0.1TB ved 10: 10. Vores overvågning alarmerede kl. 10.28 og vi erklærede en hændelse kl. 10.31. Mens vores infrastrukturhold undersøgte, løb DLV 'en ud af rummet kl. 11.15, og Postgres-sagen gik kun i gang. Dette stoppede al temporal behandling i dens spor.
Kl. 11: 42 genstartede vi Postgres for at flytte WAL-loggen fra DLV til datamængden og bruge ekstra diskplads og IOPS der. Denne manøvre havde mindsket hændelsen den 6. oktober, og vi vidste, det ville tage omkring 60 minutter.
Mens databasen var genstartet, vi begyndte at gennemføre flere load- slippe teknikker opstrøms af Temporal:
* Vi begyndte at undersøge, om vi skulle kaste indgående arbejdsbyrder helt at holde resten bevæger sig, men i sidste ende besluttede, at dette ville give ingen værdi.
* kl 12: 29, vi markeret off kredit afgifter opdateringer, som udgjorde 12% af Temporal aktiviteter. Dette forlod Pipeline Usage side med gamle opladning data, indtil vi ville backfill det, men ville ikke miste data eller forhindre rørledninger i at køre.
Kl. 12: 59, databasen var tilbage op og begyndte at behandle arbejde, der havde i kø siden 11: 15 og ved 14: 40, denne efterslæb var ryddet og job var begyndt til tiden. Men ved 15: 15, forsinkelser returneres som databasens routing oprydning var faldet langt bagud på tabellerne Temporal bruger til at spore kø og planlagt arbejde. Disse tabeller holder normalt titusindvis af slettede rækker venter oprydning, men sent om eftermiddagen, de holdt titusinder af rækker. Hver temporal operation skulle læse forbi disse rækker, så databasen brugte meget mere tid på hver enkelt og Temporal løb langsommere. Dette resulterede i, at kunderne fortsatte med at se timelange forsinkelser i start af rørledninger og i statusopdateringer.
I de næste par timer forsøgte vi forskellige lempelser, herunder:
* Manipulerer Temporale konfigurationsværdier for at reducere databasetryk. Dette havde minimal effekt.
* Kører manuel vakuum job til at rydde op døde rækker i Postgres. Dette endte med at konkurrere om CPU med forespørgsler selv, og var i sidste ende kontraproduktiv. Vi aflyste dem kl. 17.45 for at lette trykket på databasen.
* Vi begyndte at forsøge at flytte alle meddelelser usecases til en separat temporal instans. Dette udgjorde 18% af temporale aktiviteter. Vi afsluttede med at flytte meddelelser kl. 17.07.
* Kl. 17: 16 gennemførte vi med succes en optimering af vores repræsentation af rørledningstilstand, hvilket reducerede den med 5%. Det igen reduceret størrelsen af databasen skriver og derfor datapres på Postgres WAL log.
Ingen af disse afbødede spørgsmålet fuldt ud.
Ved 20: 48, vi indså, at Postgres var nu prygl på databasen CPU og var ikke længere flaskehalset på log skriver. Vi indså endvidere, at vores opstrømssystemer både indsendte nyt arbejde og også forsøgte arbejde, der tidligere var blevet indsendt og mislykkedes. I erkendelse af, at vi var i en klassisk genprøve storm, vi holdt pause alle indgående og genprøve arbejde og lad det køle op, for at tillade databasen til fuldt ud at fuldføre in- proces arbejde. Derefter fik vi langsomt kastet op i kø fra 22: 07 for at holde databasen på en bæredygtig belastning.
Dette lykkedes fuldt ud med 23: 47, da alt arbejde i kø var begyndt, og vi lukkede hændelsen kl. 02: 08 den 10. oktober.
# Fremtidig forebyggelse og procesforbedring
Flere tidsmæssige omstændigheder
Parallelt med hændelse afbødning og opløsning, starter på 19: 11 den 9. oktober, vi også begyndte at stå op flere skæggede Temporal tilfælde og gennemføre evnen til at load- balance indgående arbejde mellem dem.
Hver af de mange temporale tilfælde vedligeholder sin egen uafhængige database og arbejderklynger, og så er isoleret fra de andre. Som en post mortem action post fra den 6. oktober, havde vi allerede planlagt infrastruktur arbejde, der ville have fjernet flaskehalsen i en enkelt temporal instans og Postgres database, der starter den 12. oktober og forventer at tage 2 uger. Den 9. oktober indså vi, at dette arbejde simpelthen ikke kunne vente, så vores ingeniørhold implementeret, testet og rullet ud en enklere version af de planlagte ændringer inden for et par timer.
Disse ændringer afsluttet med succes på 01: 45 den 10. oktober.
* * Derudover ændrer vi hvordan vi gemmer og overvåger transaktionsjournaler. * * Vores tidsdatabase bruger ikke længere logvolumen i fast størrelse. Vi tilføjer advarsler om, hvor langt logarkivering falder bagud, og hvor hurtigt databasen skriver logfiler, så vi kan handle timer tidligere end vi gjorde den 9. oktober.
* * Vi er også på genbesøg Temporal sletning tidsplan. * * Temporal sletter færdig arbejde et par dage efter det kører, så en travl dag vender tilbage som database belastning senere i ugen. Vi ændrer hvornår og hvor hurtigt disse sletninger kører.
* * Vi ændrer hvordan vores systemer forsøger igen, når Temporal er langsom. * * Den 9. oktober, vores systemer genprøvede mislykkedes arbejde mod Temporal og tilføjet til sin belastning. Som vi forpligtede os efter den 6. oktober, er vi ved at ændre vores systemer til at vente på Temporal at komme sig, så arbejdet ikke er tabt.
# # Konklusion
Kundeoplevelsen er vores topprioritet, og vi forpligter os til løbende at forbedre pålideligheden af vores systemer til at matche den tillid, som vores kunder lægger i os. Vi takker vores kunder for deres tålmodighed, mens vores team arbejdede for at løse disse hændelser.
Kontakt vores supporthold med spørgsmål eller bekymringer.
Automatisk oversat fra den officielle hændelsesopdatering.
Forhøjede ventetider for maskinjob
Startede 8. oktober 2026 kl. 13.00 UTC · 3h 35m
IssuesMindre hændelse
Berørte komponenter
Machine Jobs
identified
Kunderne kan opleve forhøjede ventetider for maskinjob. Vi arbejder på at løse dette problem.
identified
Kunder, der bruger Linux maskine job oplever forhøjede ventetider, i gennemsnit omkring 11 minutter, med den længste ventetid overstiger 30 minutter på medium, arm.medium og arm.large ressource klasser. Vores ingeniører har identificeret problemet og arbejder på et fix. Vi vil levere endnu en opdatering kl 14: 00 UTC.
identified
Kunder, der bruger Linux-maskine job oplever forhøjede ventetider, i gennemsnit omkring 40 minutter, med den længste ventetid overstiger 50 minutter. De fleste Linux maskine ressource klasser er påvirket, herunder medium, store, xlarge, 2xlarge og deres Arm ækvivalenter. Vores ingeniører har identificeret problemet og arbejder på et fix. Vi vil levere endnu en opdatering inden 14: 30 UTC.
identified
Kunder, der bruger Linux maskine job og remote Docker oplever forhøjede ventetider. Ventetider er begyndt at falde og nu gennemsnit omkring 20 minutter, med de længste ventetider overstiger 40 minutter på nogle ressource klasser. Vores ingeniører har identificeret problemet og arbejder på et fix. Vi vil give endnu en opdatering inden 15: 00 UTC.
identified
En rettelse er blevet indsat, og ventetiden er faldende, men kunder, der bruger Linux maskine job og Remote Docker er stadig oplever forsinkelser. Vent gange i øjeblikket gennemsnit omkring 11 minutter, med den længste ventetid overstiger 35 minutter på nogle ressource klasser. Vi arbejder på at øge kapaciteten så hurtigt som muligt. Vi vil levere endnu en opdatering inden 15: 30 UTC.
identified
Ventetider fortsætter med at falde, men kunder, der bruger Linux maskine job og remote Docker er stadig oplever forsinkelser. Vent gange i øjeblikket gennemsnit omkring 6 minutter. De længste ventetider, op til omkring 20 minutter, er på 2xlarge, arm.2xlarge og gpu.nvidia. små ressourceklasser. Vi arbejder på at øge kapaciteten så hurtigt som muligt. Vi vil levere endnu en opdatering kl 16: 00 UTC.
identified
Ventetider fortsætter med at falde, men kunder, der bruger Linux maskine job og remote Docker er stadig oplever forsinkelser. Vent gange i øjeblikket gennemsnit omkring 90 sekunder, med den længste ventetid op til omkring 6 minutter på nogle ressource klasser. Vi arbejder på at øge kapaciteten så hurtigt som muligt. Vi vil levere endnu en opdatering kl 16: 30 UTC.
monitoring
Ventetider for kunder, der bruger Linux-maskine job og remote Docker er vendt tilbage til normal. Vi overvåger, at ventetiden forbliver stabil, mens vi fortsætter med at tilføje kapacitet. Vi vil levere endnu en opdatering kl 16: 30 UTC.
resolved
Mellem 12: 40 UTC og 16: 00 UTC den 8. oktober, kunder ved hjælp af Linux maskine job og remote Docker oplevet forhøjede ventetider. Spørgsmålet er blevet løst, og ventetiden er blevet normal igen. Vi takker dig for din tålmodighed, mens vores team arbejdede på at gennemføre et fix.
postmortem
# * * Oversigt * *
Mellem den 1. oktober og den 8. oktober 2026 oplevede CircleCI-kunderne fem separate hændelser, hvor job ventede længere end normalt for at starte eller ikke startede. Tre af hændelserne blev drevet af begrænsede eksempler tilgængelighed fra vores cloud-udbyder. En var forårsaget af et konfigurationsproblem i vores planlægning infrastruktur, og en af hukommelsesbegrænsninger på en intern tjeneste, som vi rejste under hændelsen.
* * * Oktober 1, 07: 57 til 10: 24 UTC: * * Docker Gen 2 job ventede op til 30 minutter til at starte. Et konfigurationsproblem forhindrede Gen 2-planlægningsserverne i at bruge deres højtydende lokale diske. Under et udbrud i trafikken, faldt fallback disketterne mættet og jobplacering langsommere.
* * * 7. oktober, 13: 27 til 14: 06 UTC: * * Machine job ventede længere end normalt, fordi vi ikke kunne erhverve nok virtuelle maskiner fra vores cloud udbyder.
* * * 7. oktober, 14: 24 til 15: 21 UTC: * * Nogle job mislykkedes med en infrastrukturfejl, og arbejdsgange blev forsinket. Den service, der giver hvert job sin konfiguration ved opstart løb tør for hukommelse og genstartet.
* * * 7. oktober 18: 49 til 20: 05 UTC: * * Docker Gen 2 job ventede længere end normalt, fordi vi ikke kunne erhverve nok tilfælde fra vores cloud udbyder.
* * * 8. oktober, 12: 48 til 16: 00 UTC: * * Linux maskine job og fjernbetjening Docker job ventede op til 50 minutter til at starte. Vores cloud-udbyder havde ikke nok af den instans type, vi anmoder om, og en fejl i logikken, der vælger en anden instans type afholdt os fra at bruge alternativer.
Jobs, der ventede under disse hændelser blev forsinket, ikke tabt. Kunder, hvis job mislykkedes med en infrastrukturfejl i oktober 7 hændelsen fra 14: 24 til 15: 21 UTC kan genkøre dem.
De oprindelige statussider kan findes nedenfor:
[1. oktober - Forsinkelser ved start af Gen 2 Docker Jobs] (https: / / status.circleci.com / hændelser / 22mrv46g6n7g)
* [7. oktober - Forsinkelse på start Machine Job Opgaver] (https: / / status.circleci.com / hændelser / tj6wdnfjwr64)
* [7. oktober - Forhøjet niveau af infraa mislykkes på kundejob] (https: / / status.circleci.com / hændelser / 0z31ldjd8m5v)
[7. oktober - Øget ventetid for Docker Gen2] (https: / / status.circleci.com / hændelser / 39rfrjmk5pvd)
* [8. oktober - Forhøjede ventetider for maskinjob] (https: / / status.circleci.com / hændelser / jn756xtsy4xg)
# * * Baggrund * *
Hvert job, der kører på CircleCI skal beregnes. Hvor denne beregning kommer fra afhænger af eksekutor.
Docker job kører på klynger af servere, der tidsplan arbejde på en flåde af tilfælde. Scheduler er software på de servere, der beslutter, hvilken instans kører hvert job. Gen 2 Docker job kørte på en sådan klynge på tidspunktet for oktober 1 hændelse. Gen 1 Docker job er spredt over flere klynger.
Machine job, herunder fjernbetjening Docker job, få en dedikeret virtuel maskine. En remote Docker job håndteres som en Linux-maskine job fra indsendelse gennem levering. Vores maskine levering service anmoder hver maskine fra vores cloud-udbyder i en af de to regioner, vi normalt bruger til maskine job. Når udbyderen ikke kan levere den instans type, vi anmoder om, tjenesten falder tilbage: det kræver en anden instans type, eller en anden region, fra en liste, vi vedligeholder. Et job venter, indtil en maskine er tilgængelig.
Når et job starter, beder det en jobkonfigurationstjeneste om dets konfiguration. Denne tjeneste kører som et sæt kapsler, som er små kopier af det samme program. Hvis for mange kapsler stopper, bærer de resterende kapsler mere last, og job kan ikke starte, før tjenesten kommer sig.
Disse stier afhænger af tre slags kapacitet: gennemløbet af vores planlægningssystemer, levering af instanser fra vores cloud-udbyder, og hukommelse og antal kopier af de tjenester, der starter job. En mangel på nogen af dem gør job vente eller mislykkes.
Hvad skete der?
_\ (Alle gange UTC\)
# # # * * Oktober 1: Docker Gen 2 job forsinket op til 30 minutter * *
Kl. 07: 44 steg diskaktiviteten på de servere, der planlagde Gen 2 Docker job til 90% af kapaciteten og blev der. Kl. 07: 57 begyndte antallet af Docker-job at vokse, og ventetiden steg med det. En automatisk alarm tilkaldte on- call ingeniør kl 08: 08. Vi erklærede en hændelse kl. 08: 42.
Kl. 08: 43 identificerede ingeniørerne highdisk latency på planlægningsserverne. De første troede diskene var for langsom til belastningen, så de forberedte en ændring til en hurtigere disk type. Kl. 09: 01 blev holdet enige om to arbejdsstrømme: flytte serverne til hurtigere diske, og tilføje en anden Gen 2 klynge, så job ville splitte på tværs af to klynger.
Kl. 09: 41 fandt ingeniører årsagen. Hver planlægning server har hurtige diske knyttet direkte til det, og scheduler er beregnet til at holde sine arbejdsdata der. Disse servere kører på en security- hærdet styresystem billede, og på dette billede de hurtige diske blev ikke brugt. Scheduler skrev sine data til langsommere netværksforbundne diske i stedet. Scriptet, der opsætter de hurtige diske mislykkedes uden en fejl, og et hul i logning på disse servere skjulte fejlen. Gen 2-trafikken var også blevet mere og mere eksplosiv. De langsommere diske mættet under disse sprængninger, og scheduler faldt bagud.
Ventetider toppede kl 09: 54, da job på Gen 2 medium ressource klasse ventede op til 30 minutter. Kl. 09: 55 anvendte ingeniører et fix, der satte de hurtige diske op korrekt. Kl. 10: 11 begyndte scheduler at placere job hurtigere, hvilket bekræftede serverne kunne holde trit med nye job. Ventetider for Gen 2 medium faldt til 13 minutter ved 10: 14, 7 minutter ved 10: 17, og 1 minut 30 sekunder ved 10: 20. Vi flyttede statussiden til overvågning kl. 10.24 og løste hændelsen kl. 10.45.
Kl. 11.20 begyndte den anden Gen 2-klynge at drive job.
# # # * * 7. oktober 13: 27 til 14: 06: Forhøjede ventetider for maskinjobs * *
Vi erklærede en hændelse kl 13: 27 efter at have set forhøjet kø og ventetider. Vi skrev til status side på 13: 31. Kl. 13: 31 så ingeniører, at vi kæmpede for at erhverve virtuelle maskiner til maskinjob, og at antallet af job, der ventede på at starte, var højt primært for maskinjob. Kl. 13.34 blev ventetiden hævet på tværs af eksekutorerne.
kl. 13.48 begyndte ventetiden at komme sig, da flere maskiner blev tilgængelige, og vi løste hændelsen kl. 14.06.
# # # * * 7. oktober, 14: 24 til 15: 21: Jobsvigt og forsinkelser i arbejdsgangen * *
Kort efter den forrige hændelse var markeret som løst, erklærede vi en ny hændelse kl. 14: 24 på grund af et kraftigt fald i antallet af job, der blev indsendt til vores gennemførelsessystemer. Kl. 14: 26 så ingeniører, at kapslerne fra jobkonfigurationstjenesten var ved at starte forfra. Pods, der genstarter efterlader færre kopier af tjenesten til at besvare anmodninger, og job, der ikke kunne hente deres konfiguration efter gentagne forsøg mislykkedes med en infrastrukturfejl. Arbejdsgange, der allerede kørte ventede på opdateringer fra job, der ikke var startet.
Kl. 14.35 øgede ingeniørerne mængden af tilgængelig hukommelse til kapslerne og øgede antallet af kapsler, hvilket gav tjenesten flere kopier til at dele byrden. Vi har også øget mængden af hukommelse tilgængelige Job indlæg begyndte at komme sig, og antallet af beskeder flyder gennem vores workflow system vendte tilbage til normale niveauer. Kl. 14.44 flyttede vi statussiden til overvågning.
Pods i jobkonfiguration service nåede deres hukommelse grænser og genstartet. Vi øgede hukommelsen og pod tæller, og tjenesten kom sig. Kl. 15: 13 øgede vi antallet af tilfælde i vores Gen 2 Docker-klynger, så vi hurtigt kunne arbejde os igennem en ophobning af ventende job. Vi løste hændelsen kl. 15: 21.
# # # * * 7. oktober 18: 49 til 20: 05: Forhøjede ventetider for Docker Gen 2 jobs * *
Vi erklærede en ny hændelse kl 18: 49 efter Docker Gen 2 ventetider steg. Kl. 18: 51 bekræftede ingeniører, at mangel på tilgængelige tilfælde forhindrede os i at erhverve nok af dem, som hævede ventetider. Ventetider afveg efter ressourceklassestørrelse.
kl 19: 52, gennemsnitlige ventetider var lavere end en time tidligere som mere kapacitet blev til rådighed, selvom korte pigge fortsatte, og vi flyttede status side til overvågning. Vi løste hændelsen kl. 20.05.
# # # * * 8. oktober: Linux-maskine og eksterne Docker job venter op til 50 minutter * *
Vi erklærede en hændelse kl 12: 48 efter at have set et stort antal job venter på at starte og lange ventetider for maskine og fjernbetjening Docker job. Kl. 12: 49 så ingeniører, at vores cloud-udbyder ikke kunne levere nok tilfælde. Forsinkelser fortsatte med at klatre som vi undersøgte.
Kl. 13: 13 begyndte vi at undersøge logikken, der vælger en anden instans type eller region, når vores første valg er utilgængelig. Kl. 13: 24 havde vi mistanke om, at en fejl i denne logik forhindrede os i at bruge andre eksempler i vores primære region, så vi deaktiverede vores fallback-region og bekræftede årsagen til fejlen. Ingeniører begyndte at arbejde på et fix og indsat det på 14: 49. Tjenesten begyndte at anmode om andre eksempler typer og startede maskiner i stort antal. Kl. 14.58 faldt antallet af jobs, der ventede på en maskine, støt. Gennemsnitlige ventetider på tværs af ressourceklasser fortsatte med at falde i løbet af den næste time, da vi arbejdede gennem backlog af ventende job.
kl. 16: 00, køen af job venter på en maskine ryddet og antallet af ventende job tilbage til normal. Vi flyttede statussiden til overvågning kl. 16.09 og løste hændelsen kl. 16.35.
# # * * Fremtidig forebyggelse og procesforbedring * *
Vi tager følgende skridt til at styrke modstandsdygtigheden i jobstarttider, herunder diversificering af udbuddet, fallback-logik og tidligere opdagelse.
* * Vi udvider vores computerregioner. * * I den 7. oktober og 8. oktober kunne vores cloud-udbyder ikke levere nok tilfælde i de regioner, vi brugte. Vi tilføjer nye regioner til vores fallback-logik for at håndtere stigninger i efterspørgslen, der overstiger vores foretrukne regioner.
* * Vi er ved at fastsætte den logik, der vælger en anden instans type. * * Den 8. oktober forhindrede en defekt, at maskinereservatoren brugte andre typer af cases i samme region. Vi har indsat en rettelse under hændelsen og er nu at gennemgå og refaktorere denne logik som helhed, med tests, så en mangel på en instans type flytter arbejde til en anden.
* * Vi udvider de eksempler typer, vi tilbyder og sikrer ekstra kapacitet. * * Vi samarbejder med vores cloud-udbyder om at reservere ekstra kapacitet i vores eksisterende regioner, og vi tilføjer eksempler typer, som job kan køre på. Industriens efterspørgsel efter højtydende beregninger er stigende. Vi diversificerer hvor og hvordan vi leverer kapacitet, så vores kunder er isoleret fra forsyningsvariationen.
* * Vi tilføjede en anden Gen 2 Docker klynge så trafik sprængninger er fordelt på to klynger. * * Vi tilføjer også advarsler om planlægning server disk mætning og om, hvor hurtigt scheduler placerer job, og en alarm, der skyder, når en server starter uden sine hurtige diske i brug. Vi gjorde disk setup script mislykkes med en fejl, og vi restaurerede log forsendelse fra disse servere, så et lignende problem er synlig før.
Kundeoplevelsen er vores topprioritet, og vi forpligter os til løbende at forbedre pålideligheden af vores systemer til at matche den tillid, som vores kunder lægger i os. Vi takker vores kunder for deres tålmodighed, mens vores team arbejdede for at løse disse hændelser. Kontakt vores supporthold med spørgsmål eller bekymringer.
Automatisk oversat fra den officielle hændelsesopdatering.
Øget arbejdsventetid for Docker Gen2
Startede 7. oktober 2026 kl. 18.54 UTC · 1h 11m
IssuesMindre hændelse
Berørte komponenter
Docker Jobs
identified
Der er en øget ventetid for job på Docker Gen2.
identified
Bemærk: forsinkelser vil være mere mærkbar for folk, der kører på Docker 'xlarge' og derover.
monitoring
Vi ser stadig spikes i opgave ventetider men i gennemsnit venter gange ser bedre for alle Docker Gen2.
resolved
Denne hændelse er blevet løst.
postmortem
# * * Oversigt * *
Mellem den 1. oktober og den 8. oktober 2026 oplevede CircleCI-kunderne fem separate hændelser, hvor job ventede længere end normalt for at starte eller ikke startede. Tre af hændelserne blev drevet af begrænsede eksempler tilgængelighed fra vores cloud-udbyder. En var forårsaget af et konfigurationsproblem i vores planlægning infrastruktur, og en af hukommelsesbegrænsninger på en intern tjeneste, som vi rejste under hændelsen.
* * * Oktober 1, 07: 57 til 10: 24 UTC: * * Docker Gen 2 job ventede op til 30 minutter til at starte. Et konfigurationsproblem forhindrede Gen 2-planlægningsserverne i at bruge deres højtydende lokale diske. Under et udbrud i trafikken, faldt fallback disketterne mættet og jobplacering langsommere.
* * * 7. oktober, 13: 27 til 14: 06 UTC: * * Machine job ventede længere end normalt, fordi vi ikke kunne erhverve nok virtuelle maskiner fra vores cloud udbyder.
* * * 7. oktober, 14: 24 til 15: 21 UTC: * * Nogle job mislykkedes med en infrastrukturfejl, og arbejdsgange blev forsinket. Den service, der giver hvert job sin konfiguration ved opstart løb tør for hukommelse og genstartet.
* * * 7. oktober 18: 49 til 20: 05 UTC: * * Docker Gen 2 job ventede længere end normalt, fordi vi ikke kunne erhverve nok tilfælde fra vores cloud udbyder.
* * * 8. oktober, 12: 48 til 16: 00 UTC: * * Linux maskine job og fjernbetjening Docker job ventede op til 50 minutter til at starte. Vores cloud-udbyder havde ikke nok af den instans type, vi anmoder om, og en fejl i logikken, der vælger en anden instans type afholdt os fra at bruge alternativer.
Jobs, der ventede under disse hændelser blev forsinket, ikke tabt. Kunder, hvis job mislykkedes med en infrastrukturfejl i oktober 7 hændelsen fra 14: 24 til 15: 21 UTC kan genkøre dem.
De oprindelige statussider kan findes nedenfor:
[1. oktober - Forsinkelser ved start af Gen 2 Docker Jobs] (https: / / status.circleci.com / hændelser / 22mrv46g6n7g)
* [7. oktober - Forsinkelse på start Machine Job Opgaver] (https: / / status.circleci.com / hændelser / tj6wdnfjwr64)
* [7. oktober - Forhøjet niveau af infraa mislykkes på kundejob] (https: / / status.circleci.com / hændelser / 0z31ldjd8m5v)
[7. oktober - Øget ventetid for Docker Gen2] (https: / / status.circleci.com / hændelser / 39rfrjmk5pvd)
* [8. oktober - Forhøjede ventetider for maskinjob] (https: / / status.circleci.com / hændelser / jn756xtsy4xg)
# * * Baggrund * *
Hvert job, der kører på CircleCI skal beregnes. Hvor denne beregning kommer fra afhænger af eksekutor.
Docker job kører på klynger af servere, der tidsplan arbejde på en flåde af tilfælde. Scheduler er software på de servere, der beslutter, hvilken instans kører hvert job. Gen 2 Docker job kørte på en sådan klynge på tidspunktet for oktober 1 hændelse. Gen 1 Docker job er spredt over flere klynger.
Machine job, herunder fjernbetjening Docker job, få en dedikeret virtuel maskine. En remote Docker job håndteres som en Linux-maskine job fra indsendelse gennem levering. Vores maskine levering service anmoder hver maskine fra vores cloud-udbyder i en af de to regioner, vi normalt bruger til maskine job. Når udbyderen ikke kan levere den instans type, vi anmoder om, tjenesten falder tilbage: det kræver en anden instans type, eller en anden region, fra en liste, vi vedligeholder. Et job venter, indtil en maskine er tilgængelig.
Når et job starter, beder det en jobkonfigurationstjeneste om dets konfiguration. Denne tjeneste kører som et sæt kapsler, som er små kopier af det samme program. Hvis for mange kapsler stopper, bærer de resterende kapsler mere last, og job kan ikke starte, før tjenesten kommer sig.
Disse stier afhænger af tre slags kapacitet: gennemløbet af vores planlægningssystemer, levering af instanser fra vores cloud-udbyder, og hukommelse og antal kopier af de tjenester, der starter job. En mangel på nogen af dem gør job vente eller mislykkes.
Hvad skete der?
_\ (Alle gange UTC\)
# # # * * Oktober 1: Docker Gen 2 job forsinket op til 30 minutter * *
Kl. 07: 44 steg diskaktiviteten på de servere, der planlagde Gen 2 Docker job til 90% af kapaciteten og blev der. Kl. 07: 57 begyndte antallet af Docker-job at vokse, og ventetiden steg med det. En automatisk alarm tilkaldte on- call ingeniør kl 08: 08. Vi erklærede en hændelse kl. 08: 42.
Kl. 08: 43 identificerede ingeniørerne highdisk latency på planlægningsserverne. De første troede diskene var for langsom til belastningen, så de forberedte en ændring til en hurtigere disk type. Kl. 09: 01 blev holdet enige om to arbejdsstrømme: flytte serverne til hurtigere diske, og tilføje en anden Gen 2 klynge, så job ville splitte på tværs af to klynger.
Kl. 09: 41 fandt ingeniører årsagen. Hver planlægning server har hurtige diske knyttet direkte til det, og scheduler er beregnet til at holde sine arbejdsdata der. Disse servere kører på en security- hærdet styresystem billede, og på dette billede de hurtige diske blev ikke brugt. Scheduler skrev sine data til langsommere netværksforbundne diske i stedet. Scriptet, der opsætter de hurtige diske mislykkedes uden en fejl, og et hul i logning på disse servere skjulte fejlen. Gen 2-trafikken var også blevet mere og mere eksplosiv. De langsommere diske mættet under disse sprængninger, og scheduler faldt bagud.
Ventetider toppede kl 09: 54, da job på Gen 2 medium ressource klasse ventede op til 30 minutter. Kl. 09: 55 anvendte ingeniører et fix, der satte de hurtige diske op korrekt. Kl. 10: 11 begyndte scheduler at placere job hurtigere, hvilket bekræftede serverne kunne holde trit med nye job. Ventetider for Gen 2 medium faldt til 13 minutter ved 10: 14, 7 minutter ved 10: 17, og 1 minut 30 sekunder ved 10: 20. Vi flyttede statussiden til overvågning kl. 10.24 og løste hændelsen kl. 10.45.
Kl. 11.20 begyndte den anden Gen 2-klynge at drive job.
# # # * * 7. oktober 13: 27 til 14: 06: Forhøjede ventetider for maskinjobs * *
Vi erklærede en hændelse kl 13: 27 efter at have set forhøjet kø og ventetider. Vi skrev til status side på 13: 31. Kl. 13: 31 så ingeniører, at vi kæmpede for at erhverve virtuelle maskiner til maskinjob, og at antallet af job, der ventede på at starte, var højt primært for maskinjob. Kl. 13.34 blev ventetiden hævet på tværs af eksekutorerne.
kl. 13.48 begyndte ventetiden at komme sig, da flere maskiner blev tilgængelige, og vi løste hændelsen kl. 14.06.
# # # * * 7. oktober, 14: 24 til 15: 21: Jobsvigt og forsinkelser i arbejdsgangen * *
Kort efter den forrige hændelse var markeret som løst, erklærede vi en ny hændelse kl. 14: 24 på grund af et kraftigt fald i antallet af job, der blev indsendt til vores gennemførelsessystemer. Kl. 14: 26 så ingeniører, at kapslerne fra jobkonfigurationstjenesten var ved at starte forfra. Pods, der genstarter efterlader færre kopier af tjenesten til at besvare anmodninger, og job, der ikke kunne hente deres konfiguration efter gentagne forsøg mislykkedes med en infrastrukturfejl. Arbejdsgange, der allerede kørte ventede på opdateringer fra job, der ikke var startet.
Kl. 14.35 øgede ingeniørerne mængden af tilgængelig hukommelse til kapslerne og øgede antallet af kapsler, hvilket gav tjenesten flere kopier til at dele byrden. Vi har også øget mængden af hukommelse tilgængelige Job indlæg begyndte at komme sig, og antallet af beskeder flyder gennem vores workflow system vendte tilbage til normale niveauer. Kl. 14.44 flyttede vi statussiden til overvågning.
Pods i jobkonfiguration service nåede deres hukommelse grænser og genstartet. Vi øgede hukommelsen og pod tæller, og tjenesten kom sig. Kl. 15: 13 øgede vi antallet af tilfælde i vores Gen 2 Docker-klynger, så vi hurtigt kunne arbejde os igennem en ophobning af ventende job. Vi løste hændelsen kl. 15: 21.
# # # * * 7. oktober 18: 49 til 20: 05: Forhøjede ventetider for Docker Gen 2 jobs * *
Vi erklærede en ny hændelse kl 18: 49 efter Docker Gen 2 ventetider steg. Kl. 18: 51 bekræftede ingeniører, at mangel på tilgængelige tilfælde forhindrede os i at erhverve nok af dem, som hævede ventetider. Ventetider afveg efter ressourceklassestørrelse.
kl 19: 52, gennemsnitlige ventetider var lavere end en time tidligere som mere kapacitet blev til rådighed, selvom korte pigge fortsatte, og vi flyttede status side til overvågning. Vi løste hændelsen kl. 20.05.
# # # * * 8. oktober: Linux-maskine og eksterne Docker job venter op til 50 minutter * *
Vi erklærede en hændelse kl 12: 48 efter at have set et stort antal job venter på at starte og lange ventetider for maskine og fjernbetjening Docker job. Kl. 12: 49 så ingeniører, at vores cloud-udbyder ikke kunne levere nok tilfælde. Forsinkelser fortsatte med at klatre som vi undersøgte.
Kl. 13: 13 begyndte vi at undersøge logikken, der vælger en anden instans type eller region, når vores første valg er utilgængelig. Kl. 13: 24 havde vi mistanke om, at en fejl i denne logik forhindrede os i at bruge andre eksempler i vores primære region, så vi deaktiverede vores fallback-region og bekræftede årsagen til fejlen. Ingeniører begyndte at arbejde på et fix og indsat det på 14: 49. Tjenesten begyndte at anmode om andre eksempler typer og startede maskiner i stort antal. Kl. 14.58 faldt antallet af jobs, der ventede på en maskine, støt. Gennemsnitlige ventetider på tværs af ressourceklasser fortsatte med at falde i løbet af den næste time, da vi arbejdede gennem backlog af ventende job.
kl. 16: 00, køen af job venter på en maskine ryddet og antallet af ventende job tilbage til normal. Vi flyttede statussiden til overvågning kl. 16.09 og løste hændelsen kl. 16.35.
# # * * Fremtidig forebyggelse og procesforbedring * *
Vi tager følgende skridt til at styrke modstandsdygtigheden i jobstarttider, herunder diversificering af udbuddet, fallback-logik og tidligere opdagelse.
* * Vi udvider vores computerregioner. * * I den 7. oktober og 8. oktober kunne vores cloud-udbyder ikke levere nok tilfælde i de regioner, vi brugte. Vi tilføjer nye regioner til vores fallback-logik for at håndtere stigninger i efterspørgslen, der overstiger vores foretrukne regioner.
* * Vi er ved at fastsætte den logik, der vælger en anden instans type. * * Den 8. oktober forhindrede en defekt, at maskinereservatoren brugte andre typer af cases i samme region. Vi har indsat en rettelse under hændelsen og er nu at gennemgå og refaktorere denne logik som helhed, med tests, så en mangel på en instans type flytter arbejde til en anden.
* * Vi udvider de eksempler typer, vi tilbyder og sikrer ekstra kapacitet. * * Vi samarbejder med vores cloud-udbyder om at reservere ekstra kapacitet i vores eksisterende regioner, og vi tilføjer eksempler typer, som job kan køre på. Industriens efterspørgsel efter højtydende beregninger er stigende. Vi diversificerer hvor og hvordan vi leverer kapacitet, så vores kunder er isoleret fra forsyningsvariationen.
* * Vi tilføjede en anden Gen 2 Docker klynge så trafik sprængninger er fordelt på to klynger. * * Vi tilføjer også advarsler om planlægning server disk mætning og om, hvor hurtigt scheduler placerer job, og en alarm, der skyder, når en server starter uden sine hurtige diske i brug. Vi gjorde disk setup script mislykkes med en fejl, og vi restaurerede log forsendelse fra disse servere, så et lignende problem er synlig før.
Kundeoplevelsen er vores topprioritet, og vi forpligter os til løbende at forbedre pålideligheden af vores systemer til at matche den tillid, som vores kunder lægger i os. Vi takker vores kunder for deres tålmodighed, mens vores team arbejdede for at løse disse hændelser. Kontakt vores supporthold med spørgsmål eller bekymringer.
Automatisk oversat fra den officielle hændelsesopdatering.
Forhøjet niveau for infralydelser på kundejob
Startede 7. oktober 2026 kl. 14.27 UTC · 54m
IssuesMindre hændelse
Berørte komponenter
Pipelines & Workflows
investigating
Vi er ved at undersøge en stigning i infraa mislykkes for kundejob.
monitoring
Vi ser tegn på bedring. Docker Gen2 ventetider er lidt forhøjet, og vi overvåger.
resolved
Denne hændelse er blevet løst.
postmortem
# * * Oversigt * *
Mellem den 1. oktober og den 8. oktober 2026 oplevede CircleCI-kunderne fem separate hændelser, hvor job ventede længere end normalt for at starte eller ikke startede. Tre af hændelserne blev drevet af begrænsede eksempler tilgængelighed fra vores cloud-udbyder. En var forårsaget af et konfigurationsproblem i vores planlægning infrastruktur, og en af hukommelsesbegrænsninger på en intern tjeneste, som vi rejste under hændelsen.
* * * Oktober 1, 07: 57 til 10: 24 UTC: * * Docker Gen 2 job ventede op til 30 minutter til at starte. Et konfigurationsproblem forhindrede Gen 2-planlægningsserverne i at bruge deres højtydende lokale diske. Under et udbrud i trafikken, faldt fallback disketterne mættet og jobplacering langsommere.
* * * 7. oktober, 13: 27 til 14: 06 UTC: * * Machine job ventede længere end normalt, fordi vi ikke kunne erhverve nok virtuelle maskiner fra vores cloud udbyder.
* * * 7. oktober, 14: 24 til 15: 21 UTC: * * Nogle job mislykkedes med en infrastrukturfejl, og arbejdsgange blev forsinket. Den service, der giver hvert job sin konfiguration ved opstart løb tør for hukommelse og genstartet.
* * * 7. oktober 18: 49 til 20: 05 UTC: * * Docker Gen 2 job ventede længere end normalt, fordi vi ikke kunne erhverve nok tilfælde fra vores cloud udbyder.
* * * 8. oktober, 12: 48 til 16: 00 UTC: * * Linux maskine job og fjernbetjening Docker job ventede op til 50 minutter til at starte. Vores cloud-udbyder havde ikke nok af den instans type, vi anmoder om, og en fejl i logikken, der vælger en anden instans type afholdt os fra at bruge alternativer.
Jobs, der ventede under disse hændelser blev forsinket, ikke tabt. Kunder, hvis job mislykkedes med en infrastrukturfejl i oktober 7 hændelsen fra 14: 24 til 15: 21 UTC kan genkøre dem.
De oprindelige statussider kan findes nedenfor:
[1. oktober - Forsinkelser ved start af Gen 2 Docker Jobs] (https: / / status.circleci.com / hændelser / 22mrv46g6n7g)
* [7. oktober - Forsinkelse på start Machine Job Opgaver] (https: / / status.circleci.com / hændelser / tj6wdnfjwr64)
* [7. oktober - Forhøjet niveau af infraa mislykkes på kundejob] (https: / / status.circleci.com / hændelser / 0z31ldjd8m5v)
[7. oktober - Øget ventetid for Docker Gen2] (https: / / status.circleci.com / hændelser / 39rfrjmk5pvd)
* [8. oktober - Forhøjede ventetider for maskinjob] (https: / / status.circleci.com / hændelser / jn756xtsy4xg)
# * * Baggrund * *
Hvert job, der kører på CircleCI skal beregnes. Hvor denne beregning kommer fra afhænger af eksekutor.
Docker job kører på klynger af servere, der tidsplan arbejde på en flåde af tilfælde. Scheduler er software på de servere, der beslutter, hvilken instans kører hvert job. Gen 2 Docker job kørte på en sådan klynge på tidspunktet for oktober 1 hændelse. Gen 1 Docker job er spredt over flere klynger.
Machine job, herunder fjernbetjening Docker job, få en dedikeret virtuel maskine. En remote Docker job håndteres som en Linux-maskine job fra indsendelse gennem levering. Vores maskine levering service anmoder hver maskine fra vores cloud-udbyder i en af de to regioner, vi normalt bruger til maskine job. Når udbyderen ikke kan levere den instans type, vi anmoder om, tjenesten falder tilbage: det kræver en anden instans type, eller en anden region, fra en liste, vi vedligeholder. Et job venter, indtil en maskine er tilgængelig.
Når et job starter, beder det en jobkonfigurationstjeneste om dets konfiguration. Denne tjeneste kører som et sæt kapsler, som er små kopier af det samme program. Hvis for mange kapsler stopper, bærer de resterende kapsler mere last, og job kan ikke starte, før tjenesten kommer sig.
Disse stier afhænger af tre slags kapacitet: gennemløbet af vores planlægningssystemer, levering af instanser fra vores cloud-udbyder, og hukommelse og antal kopier af de tjenester, der starter job. En mangel på nogen af dem gør job vente eller mislykkes.
Hvad skete der?
_\ (Alle gange UTC\)
# # # * * Oktober 1: Docker Gen 2 job forsinket op til 30 minutter * *
Kl. 07: 44 steg diskaktiviteten på de servere, der planlagde Gen 2 Docker job til 90% af kapaciteten og blev der. Kl. 07: 57 begyndte antallet af Docker-job at vokse, og ventetiden steg med det. En automatisk alarm tilkaldte on- call ingeniør kl 08: 08. Vi erklærede en hændelse kl. 08: 42.
Kl. 08: 43 identificerede ingeniørerne highdisk latency på planlægningsserverne. De første troede diskene var for langsom til belastningen, så de forberedte en ændring til en hurtigere disk type. Kl. 09: 01 blev holdet enige om to arbejdsstrømme: flytte serverne til hurtigere diske, og tilføje en anden Gen 2 klynge, så job ville splitte på tværs af to klynger.
Kl. 09: 41 fandt ingeniører årsagen. Hver planlægning server har hurtige diske knyttet direkte til det, og scheduler er beregnet til at holde sine arbejdsdata der. Disse servere kører på en security- hærdet styresystem billede, og på dette billede de hurtige diske blev ikke brugt. Scheduler skrev sine data til langsommere netværksforbundne diske i stedet. Scriptet, der opsætter de hurtige diske mislykkedes uden en fejl, og et hul i logning på disse servere skjulte fejlen. Gen 2-trafikken var også blevet mere og mere eksplosiv. De langsommere diske mættet under disse sprængninger, og scheduler faldt bagud.
Ventetider toppede kl 09: 54, da job på Gen 2 medium ressource klasse ventede op til 30 minutter. Kl. 09: 55 anvendte ingeniører et fix, der satte de hurtige diske op korrekt. Kl. 10: 11 begyndte scheduler at placere job hurtigere, hvilket bekræftede serverne kunne holde trit med nye job. Ventetider for Gen 2 medium faldt til 13 minutter ved 10: 14, 7 minutter ved 10: 17, og 1 minut 30 sekunder ved 10: 20. Vi flyttede statussiden til overvågning kl. 10.24 og løste hændelsen kl. 10.45.
Kl. 11.20 begyndte den anden Gen 2-klynge at drive job.
# # # * * 7. oktober 13: 27 til 14: 06: Forhøjede ventetider for maskinjobs * *
Vi erklærede en hændelse kl 13: 27 efter at have set forhøjet kø og ventetider. Vi skrev til status side på 13: 31. Kl. 13: 31 så ingeniører, at vi kæmpede for at erhverve virtuelle maskiner til maskinjob, og at antallet af job, der ventede på at starte, var højt primært for maskinjob. Kl. 13.34 blev ventetiden hævet på tværs af eksekutorerne.
kl. 13.48 begyndte ventetiden at komme sig, da flere maskiner blev tilgængelige, og vi løste hændelsen kl. 14.06.
# # # * * 7. oktober, 14: 24 til 15: 21: Jobsvigt og forsinkelser i arbejdsgangen * *
Kort efter den forrige hændelse var markeret som løst, erklærede vi en ny hændelse kl. 14: 24 på grund af et kraftigt fald i antallet af job, der blev indsendt til vores gennemførelsessystemer. Kl. 14: 26 så ingeniører, at kapslerne fra jobkonfigurationstjenesten var ved at starte forfra. Pods, der genstarter efterlader færre kopier af tjenesten til at besvare anmodninger, og job, der ikke kunne hente deres konfiguration efter gentagne forsøg mislykkedes med en infrastrukturfejl. Arbejdsgange, der allerede kørte ventede på opdateringer fra job, der ikke var startet.
Kl. 14.35 øgede ingeniørerne mængden af tilgængelig hukommelse til kapslerne og øgede antallet af kapsler, hvilket gav tjenesten flere kopier til at dele byrden. Vi har også øget mængden af hukommelse tilgængelige Job indlæg begyndte at komme sig, og antallet af beskeder flyder gennem vores workflow system vendte tilbage til normale niveauer. Kl. 14.44 flyttede vi statussiden til overvågning.
Pods i jobkonfiguration service nåede deres hukommelse grænser og genstartet. Vi øgede hukommelsen og pod tæller, og tjenesten kom sig. Kl. 15: 13 øgede vi antallet af tilfælde i vores Gen 2 Docker-klynger, så vi hurtigt kunne arbejde os igennem en ophobning af ventende job. Vi løste hændelsen kl. 15: 21.
# # # * * 7. oktober 18: 49 til 20: 05: Forhøjede ventetider for Docker Gen 2 jobs * *
Vi erklærede en ny hændelse kl 18: 49 efter Docker Gen 2 ventetider steg. Kl. 18: 51 bekræftede ingeniører, at mangel på tilgængelige tilfælde forhindrede os i at erhverve nok af dem, som hævede ventetider. Ventetider afveg efter ressourceklassestørrelse.
kl 19: 52, gennemsnitlige ventetider var lavere end en time tidligere som mere kapacitet blev til rådighed, selvom korte pigge fortsatte, og vi flyttede status side til overvågning. Vi løste hændelsen kl. 20.05.
# # # * * 8. oktober: Linux-maskine og eksterne Docker job venter op til 50 minutter * *
Vi erklærede en hændelse kl 12: 48 efter at have set et stort antal job venter på at starte og lange ventetider for maskine og fjernbetjening Docker job. Kl. 12: 49 så ingeniører, at vores cloud-udbyder ikke kunne levere nok tilfælde. Forsinkelser fortsatte med at klatre som vi undersøgte.
Kl. 13: 13 begyndte vi at undersøge logikken, der vælger en anden instans type eller region, når vores første valg er utilgængelig. Kl. 13: 24 havde vi mistanke om, at en fejl i denne logik forhindrede os i at bruge andre eksempler i vores primære region, så vi deaktiverede vores fallback-region og bekræftede årsagen til fejlen. Ingeniører begyndte at arbejde på et fix og indsat det på 14: 49. Tjenesten begyndte at anmode om andre eksempler typer og startede maskiner i stort antal. Kl. 14.58 faldt antallet af jobs, der ventede på en maskine, støt. Gennemsnitlige ventetider på tværs af ressourceklasser fortsatte med at falde i løbet af den næste time, da vi arbejdede gennem backlog af ventende job.
kl. 16: 00, køen af job venter på en maskine ryddet og antallet af ventende job tilbage til normal. Vi flyttede statussiden til overvågning kl. 16.09 og løste hændelsen kl. 16.35.
# # * * Fremtidig forebyggelse og procesforbedring * *
Vi tager følgende skridt til at styrke modstandsdygtigheden i jobstarttider, herunder diversificering af udbuddet, fallback-logik og tidligere opdagelse.
* * Vi udvider vores computerregioner. * * I den 7. oktober og 8. oktober kunne vores cloud-udbyder ikke levere nok tilfælde i de regioner, vi brugte. Vi tilføjer nye regioner til vores fallback-logik for at håndtere stigninger i efterspørgslen, der overstiger vores foretrukne regioner.
* * Vi er ved at fastsætte den logik, der vælger en anden instans type. * * Den 8. oktober forhindrede en defekt, at maskinereservatoren brugte andre typer af cases i samme region. Vi har indsat en rettelse under hændelsen og er nu at gennemgå og refaktorere denne logik som helhed, med tests, så en mangel på en instans type flytter arbejde til en anden.
* * Vi udvider de eksempler typer, vi tilbyder og sikrer ekstra kapacitet. * * Vi samarbejder med vores cloud-udbyder om at reservere ekstra kapacitet i vores eksisterende regioner, og vi tilføjer eksempler typer, som job kan køre på. Industriens efterspørgsel efter højtydende beregninger er stigende. Vi diversificerer hvor og hvordan vi leverer kapacitet, så vores kunder er isoleret fra forsyningsvariationen.
* * Vi tilføjede en anden Gen 2 Docker klynge så trafik sprængninger er fordelt på to klynger. * * Vi tilføjer også advarsler om planlægning server disk mætning og om, hvor hurtigt scheduler placerer job, og en alarm, der skyder, når en server starter uden sine hurtige diske i brug. Vi gjorde disk setup script mislykkes med en fejl, og vi restaurerede log forsendelse fra disse servere, så et lignende problem er synlig før.
Kundeoplevelsen er vores topprioritet, og vi forpligter os til løbende at forbedre pålideligheden af vores systemer til at matche den tillid, som vores kunder lægger i os. Vi takker vores kunder for deres tålmodighed, mens vores team arbejdede for at løse disse hændelser. Kontakt vores supporthold med spørgsmål eller bekymringer.
Automatisk oversat fra den officielle hændelsesopdatering.
Forsinkelse på start Machine Job Opgaver
Startede 7. oktober 2026 kl. 13.40 UTC · 26m
IssuesMindre hændelse
Berørte komponenter
Machine Jobs
investigating
Kunder kan opleve forhøjede ventetider for Machine Job Opgaver, vi er ved at undersøge den grundlæggende årsag og vil opdatere, når vi ved mere.
monitoring
Vi ser tegn på genopretning og overvågning af situationen.
resolved
Hændelsen er løst. Tak for din tålmodighed
postmortem
# * * Oversigt * *
Mellem den 1. oktober og den 8. oktober 2026 oplevede CircleCI-kunderne fem separate hændelser, hvor job ventede længere end normalt for at starte eller ikke startede. Tre af hændelserne blev drevet af begrænsede eksempler tilgængelighed fra vores cloud-udbyder. En var forårsaget af et konfigurationsproblem i vores planlægning infrastruktur, og en af hukommelsesbegrænsninger på en intern tjeneste, som vi rejste under hændelsen.
* * * Oktober 1, 07: 57 til 10: 24 UTC: * * Docker Gen 2 job ventede op til 30 minutter til at starte. Et konfigurationsproblem forhindrede Gen 2-planlægningsserverne i at bruge deres højtydende lokale diske. Under et udbrud i trafikken, faldt fallback disketterne mættet og jobplacering langsommere.
* * * 7. oktober, 13: 27 til 14: 06 UTC: * * Machine job ventede længere end normalt, fordi vi ikke kunne erhverve nok virtuelle maskiner fra vores cloud udbyder.
* * * 7. oktober, 14: 24 til 15: 21 UTC: * * Nogle job mislykkedes med en infrastrukturfejl, og arbejdsgange blev forsinket. Den service, der giver hvert job sin konfiguration ved opstart løb tør for hukommelse og genstartet.
* * * 7. oktober 18: 49 til 20: 05 UTC: * * Docker Gen 2 job ventede længere end normalt, fordi vi ikke kunne erhverve nok tilfælde fra vores cloud udbyder.
* * * 8. oktober, 12: 48 til 16: 00 UTC: * * Linux maskine job og fjernbetjening Docker job ventede op til 50 minutter til at starte. Vores cloud-udbyder havde ikke nok af den instans type, vi anmoder om, og en fejl i logikken, der vælger en anden instans type afholdt os fra at bruge alternativer.
Jobs, der ventede under disse hændelser blev forsinket, ikke tabt. Kunder, hvis job mislykkedes med en infrastrukturfejl i oktober 7 hændelsen fra 14: 24 til 15: 21 UTC kan genkøre dem.
De oprindelige statussider kan findes nedenfor:
[1. oktober - Forsinkelser ved start af Gen 2 Docker Jobs] (https: / / status.circleci.com / hændelser / 22mrv46g6n7g)
* [7. oktober - Forsinkelse på start Machine Job Opgaver] (https: / / status.circleci.com / hændelser / tj6wdnfjwr64)
* [7. oktober - Forhøjet niveau af infraa mislykkes på kundejob] (https: / / status.circleci.com / hændelser / 0z31ldjd8m5v)
[7. oktober - Øget ventetid for Docker Gen2] (https: / / status.circleci.com / hændelser / 39rfrjmk5pvd)
* [8. oktober - Forhøjede ventetider for maskinjob] (https: / / status.circleci.com / hændelser / jn756xtsy4xg)
# * * Baggrund * *
Hvert job, der kører på CircleCI skal beregnes. Hvor denne beregning kommer fra afhænger af eksekutor.
Docker job kører på klynger af servere, der tidsplan arbejde på en flåde af tilfælde. Scheduler er software på de servere, der beslutter, hvilken instans kører hvert job. Gen 2 Docker job kørte på en sådan klynge på tidspunktet for oktober 1 hændelse. Gen 1 Docker job er spredt over flere klynger.
Machine job, herunder fjernbetjening Docker job, få en dedikeret virtuel maskine. En remote Docker job håndteres som en Linux-maskine job fra indsendelse gennem levering. Vores maskine levering service anmoder hver maskine fra vores cloud-udbyder i en af de to regioner, vi normalt bruger til maskine job. Når udbyderen ikke kan levere den instans type, vi anmoder om, tjenesten falder tilbage: det kræver en anden instans type, eller en anden region, fra en liste, vi vedligeholder. Et job venter, indtil en maskine er tilgængelig.
Når et job starter, beder det en jobkonfigurationstjeneste om dets konfiguration. Denne tjeneste kører som et sæt kapsler, som er små kopier af det samme program. Hvis for mange kapsler stopper, bærer de resterende kapsler mere last, og job kan ikke starte, før tjenesten kommer sig.
Disse stier afhænger af tre slags kapacitet: gennemløbet af vores planlægningssystemer, levering af instanser fra vores cloud-udbyder, og hukommelse og antal kopier af de tjenester, der starter job. En mangel på nogen af dem gør job vente eller mislykkes.
Hvad skete der?
_\ (Alle gange UTC\)
# # # * * Oktober 1: Docker Gen 2 job forsinket op til 30 minutter * *
Kl. 07: 44 steg diskaktiviteten på de servere, der planlagde Gen 2 Docker job til 90% af kapaciteten og blev der. Kl. 07: 57 begyndte antallet af Docker-job at vokse, og ventetiden steg med det. En automatisk alarm tilkaldte on- call ingeniør kl 08: 08. Vi erklærede en hændelse kl. 08: 42.
Kl. 08: 43 identificerede ingeniørerne highdisk latency på planlægningsserverne. De første troede diskene var for langsom til belastningen, så de forberedte en ændring til en hurtigere disk type. Kl. 09: 01 blev holdet enige om to arbejdsstrømme: flytte serverne til hurtigere diske, og tilføje en anden Gen 2 klynge, så job ville splitte på tværs af to klynger.
Kl. 09: 41 fandt ingeniører årsagen. Hver planlægning server har hurtige diske knyttet direkte til det, og scheduler er beregnet til at holde sine arbejdsdata der. Disse servere kører på en security- hærdet styresystem billede, og på dette billede de hurtige diske blev ikke brugt. Scheduler skrev sine data til langsommere netværksforbundne diske i stedet. Scriptet, der opsætter de hurtige diske mislykkedes uden en fejl, og et hul i logning på disse servere skjulte fejlen. Gen 2-trafikken var også blevet mere og mere eksplosiv. De langsommere diske mættet under disse sprængninger, og scheduler faldt bagud.
Ventetider toppede kl 09: 54, da job på Gen 2 medium ressource klasse ventede op til 30 minutter. Kl. 09: 55 anvendte ingeniører et fix, der satte de hurtige diske op korrekt. Kl. 10: 11 begyndte scheduler at placere job hurtigere, hvilket bekræftede serverne kunne holde trit med nye job. Ventetider for Gen 2 medium faldt til 13 minutter ved 10: 14, 7 minutter ved 10: 17, og 1 minut 30 sekunder ved 10: 20. Vi flyttede statussiden til overvågning kl. 10.24 og løste hændelsen kl. 10.45.
Kl. 11.20 begyndte den anden Gen 2-klynge at drive job.
# # # * * 7. oktober 13: 27 til 14: 06: Forhøjede ventetider for maskinjobs * *
Vi erklærede en hændelse kl 13: 27 efter at have set forhøjet kø og ventetider. Vi skrev til status side på 13: 31. Kl. 13: 31 så ingeniører, at vi kæmpede for at erhverve virtuelle maskiner til maskinjob, og at antallet af job, der ventede på at starte, var højt primært for maskinjob. Kl. 13.34 blev ventetiden hævet på tværs af eksekutorerne.
kl. 13.48 begyndte ventetiden at komme sig, da flere maskiner blev tilgængelige, og vi løste hændelsen kl. 14.06.
# # # * * 7. oktober, 14: 24 til 15: 21: Jobsvigt og forsinkelser i arbejdsgangen * *
Kort efter den forrige hændelse var markeret som løst, erklærede vi en ny hændelse kl. 14: 24 på grund af et kraftigt fald i antallet af job, der blev indsendt til vores gennemførelsessystemer. Kl. 14: 26 så ingeniører, at kapslerne fra jobkonfigurationstjenesten var ved at starte forfra. Pods, der genstarter efterlader færre kopier af tjenesten til at besvare anmodninger, og job, der ikke kunne hente deres konfiguration efter gentagne forsøg mislykkedes med en infrastrukturfejl. Arbejdsgange, der allerede kørte ventede på opdateringer fra job, der ikke var startet.
Kl. 14.35 øgede ingeniørerne mængden af tilgængelig hukommelse til kapslerne og øgede antallet af kapsler, hvilket gav tjenesten flere kopier til at dele byrden. Vi har også øget mængden af hukommelse tilgængelige Job indlæg begyndte at komme sig, og antallet af beskeder flyder gennem vores workflow system vendte tilbage til normale niveauer. Kl. 14.44 flyttede vi statussiden til overvågning.
Pods i jobkonfiguration service nåede deres hukommelse grænser og genstartet. Vi øgede hukommelsen og pod tæller, og tjenesten kom sig. Kl. 15: 13 øgede vi antallet af tilfælde i vores Gen 2 Docker-klynger, så vi hurtigt kunne arbejde os igennem en ophobning af ventende job. Vi løste hændelsen kl. 15: 21.
# # # * * 7. oktober 18: 49 til 20: 05: Forhøjede ventetider for Docker Gen 2 jobs * *
Vi erklærede en ny hændelse kl 18: 49 efter Docker Gen 2 ventetider steg. Kl. 18: 51 bekræftede ingeniører, at mangel på tilgængelige tilfælde forhindrede os i at erhverve nok af dem, som hævede ventetider. Ventetider afveg efter ressourceklassestørrelse.
kl 19: 52, gennemsnitlige ventetider var lavere end en time tidligere som mere kapacitet blev til rådighed, selvom korte pigge fortsatte, og vi flyttede status side til overvågning. Vi løste hændelsen kl. 20.05.
# # # * * 8. oktober: Linux-maskine og eksterne Docker job venter op til 50 minutter * *
Vi erklærede en hændelse kl 12: 48 efter at have set et stort antal job venter på at starte og lange ventetider for maskine og fjernbetjening Docker job. Kl. 12: 49 så ingeniører, at vores cloud-udbyder ikke kunne levere nok tilfælde. Forsinkelser fortsatte med at klatre som vi undersøgte.
Kl. 13: 13 begyndte vi at undersøge logikken, der vælger en anden instans type eller region, når vores første valg er utilgængelig. Kl. 13: 24 havde vi mistanke om, at en fejl i denne logik forhindrede os i at bruge andre eksempler i vores primære region, så vi deaktiverede vores fallback-region og bekræftede årsagen til fejlen. Ingeniører begyndte at arbejde på et fix og indsat det på 14: 49. Tjenesten begyndte at anmode om andre eksempler typer og startede maskiner i stort antal. Kl. 14.58 faldt antallet af jobs, der ventede på en maskine, støt. Gennemsnitlige ventetider på tværs af ressourceklasser fortsatte med at falde i løbet af den næste time, da vi arbejdede gennem backlog af ventende job.
kl. 16: 00, køen af job venter på en maskine ryddet og antallet af ventende job tilbage til normal. Vi flyttede statussiden til overvågning kl. 16.09 og løste hændelsen kl. 16.35.
# # * * Fremtidig forebyggelse og procesforbedring * *
Vi tager følgende skridt til at styrke modstandsdygtigheden i jobstarttider, herunder diversificering af udbuddet, fallback-logik og tidligere opdagelse.
* * Vi udvider vores computerregioner. * * I den 7. oktober og 8. oktober kunne vores cloud-udbyder ikke levere nok tilfælde i de regioner, vi brugte. Vi tilføjer nye regioner til vores fallback-logik for at håndtere stigninger i efterspørgslen, der overstiger vores foretrukne regioner.
* * Vi er ved at fastsætte den logik, der vælger en anden instans type. * * Den 8. oktober forhindrede en defekt, at maskinereservatoren brugte andre typer af cases i samme region. Vi har indsat en rettelse under hændelsen og er nu at gennemgå og refaktorere denne logik som helhed, med tests, så en mangel på en instans type flytter arbejde til en anden.
* * Vi udvider de eksempler typer, vi tilbyder og sikrer ekstra kapacitet. * * Vi samarbejder med vores cloud-udbyder om at reservere ekstra kapacitet i vores eksisterende regioner, og vi tilføjer eksempler typer, som job kan køre på. Industriens efterspørgsel efter højtydende beregninger er stigende. Vi diversificerer hvor og hvordan vi leverer kapacitet, så vores kunder er isoleret fra forsyningsvariationen.
* * Vi tilføjede en anden Gen 2 Docker klynge så trafik sprængninger er fordelt på to klynger. * * Vi tilføjer også advarsler om planlægning server disk mætning og om, hvor hurtigt scheduler placerer job, og en alarm, der skyder, når en server starter uden sine hurtige diske i brug. Vi gjorde disk setup script mislykkes med en fejl, og vi restaurerede log forsendelse fra disse servere, så et lignende problem er synlig før.
Kundeoplevelsen er vores topprioritet, og vi forpligter os til løbende at forbedre pålideligheden af vores systemer til at matche den tillid, som vores kunder lægger i os. Vi takker vores kunder for deres tålmodighed, mens vores team arbejdede for at løse disse hændelser. Kontakt vores supporthold med spørgsmål eller bekymringer.
Automatisk oversat fra den officielle hændelsesopdatering.
Forsinkelser i rørledninger, arbejdsgange, UI-data og meddelelser
Startede 6. oktober 2026 kl. 16.00 UTC · 5h 18m
OutageStørre hændelse
Berørte komponenter
Pipelines & WorkflowsNotifications & Status Updates
investigating
Hvad er påvirket
Kunder, der bruger CircleCI-rørledninger og arbejdsgange, herunder UI-datavisning, udgående meddelelser og udgående webkroge.
Hvad kan du forvente
Forsinkelser i de rørledninger, der skabes, og i arbejdsgange og job, der starter. Job, workflow og rørlednings data kan tage op til 15 minutter at vise sig i EU. Udgående meddelelser og webkroge er forsinket med op til 1 minut.
Næste opdatering
Vi vil give en anden opdatering inden for 30 minutter eller da vi har mere information at dele.
investigating
Siden 15: 47 UTC, kunder kan også se mislykkede job, ud over de forsinkelser tidligere rapporteret. Vores ingeniører fortsætter med at undersøge og afbøde problemet.
identified
Fra 16: 02 UTC, rørledninger svigter helt, så ingen nye arbejdsgange eller job kører på dette tidspunkt. Ud over de forsinkelser og mislykkede job, der blev rapporteret tidligere. Vores ingeniører arbejder fortsat på at mindske problemet, og vi vil dele mere information, så snart vi har det.
identified
Fra 16: 39 UTC, er vi begyndt at se opsving for nye rørledninger og arbejdsgange bliver indsendt, og job er begyndt at køre igen. Vores ingeniører fortsætter med at arbejde på genopretning og vil dele mere information, så snart vi har det.
identified
Mens pipelines, arbejdsgange og job kører igen, kunderne kan fortsætte med at se længere end normalt forsinkelser mellem job i et workflow, og udgående meddelelser er forsinket med ca. 1 minut. Meddelelser og statusopdateringer til dit versionskontrolsystem begynder at gå ud igen.
Vores ingeniører fortsætter med at arbejde hen imod fuld bedring.
identified
Kunderne oplever fortsat længere forsinkelser end normalt mellem job i en arbejdsgang samt forsinkelser i udgående meddelelser.
Vi takker dig for din tålmodighed, mens vores ingeniører fortsætter med at undersøge og arbejde på at afbøde problemet. Vi vil dele en anden opdatering inden for de næste 30 minutter, eller før hvis mere information bliver tilgængelig.
identified
Kunderne oplever fortsat længere forsinkelser end normalt, før arbejdsgange og job starter, i nogle tilfælde op til ca. 30 minutter. Dette forbedres fra tidligere i hændelsen, men der er stadig forsinkelser. Forsinkelser i udgående meddelelser er forbedret.
Vi takker dig for din tålmodighed, mens vores ingeniører fortsætter med at arbejde hen imod at genoprette normale job starttider. Vi vil dele en anden opdatering inden for de næste 30 minutter, eller før hvis mere information bliver tilgængelig.
identified
Kunderne oplever fortsat forsinkelser. De fleste starter nu inden for cirka 20 minutter, forbedret fra omkring 40 minutter tidligere i hændelsen. Et meget lille antal arbejdsgange kan have ventet mere end 1 time.
Vores ingeniører har foretaget ændringer, der har forbedret servicestabiliteten, og den resterende forsinkelse skyldes en ophobning af arbejde, der er opbygget under hændelsen. Efterslæbet er faldende, og vi er fokuseret på at rydde det hurtigere. Vi vil dele flere oplysninger, efterhånden som fremskridtene fortsætter.
Vi takker dig for din tålmodighed, mens vores ingeniører arbejder gennem efterslæbet. Vi vil dele en anden opdatering inden for de næste 30 minutter, eller før hvis mere information bliver tilgængelig.
identified
Forsinkelser i arbejdsgange og job til at starte er fortsat faldende. De fleste starter nu inden for ca. 10 minutter, forbedret fra omkring 40 minutter tidligere i hændelsen. Et meget lille antal arbejdsgange kan have ventet mere end 1 time. Hvis dit job ikke startede, bedes du køre jobbet igen. Forsinkelser i udgående meddelelser er forbedret.
Den resterende forsinkelse skyldes en mangel på arbejde, der er opbygget under hændelsen, og denne forsinkelse er reduceret med mere end halvdelen. Vi forventer, at efterslæbet bliver ryddet om cirka 15 minutter. Vi deler endnu en opdatering, når den er ryddet, eller senest inden for de næste 30 minutter.
identified
Efterslæbet af forsinket arbejde er blevet ryddet, og arbejdsgange starter igen uden forsinkelser i meddelelser. Men kunder, der bruger Docker og Linux job på tværs af flere ressourcer klasser, herunder medium, store, og 2xlarge gen2, kan nu se job venter i køen i få minutter, før de starter. Vores ingeniører arbejder fortsat på at mindske dette problem. Hvis dit job ikke startede, bedes du køre jobbet igen.
Vi takker dig for din tålmodighed, mens vores ingeniører arbejder på dette. Vi vil dele en anden opdatering inden for de næste 30 minutter, eller før hvis mere information bliver tilgængelig.
monitoring
Arbejdsgange og job starter normalt, og ventetider for Docker og Linux job er vendt tilbage til normal. Vores ingeniører fortsætter med at overvåge dette spørgsmål. Hvis dit job ikke startede, bedes du køre jobbet igen.
Vi takker dig for din tålmodighed, mens vores ingeniører arbejder på dette. Vi vil dele en anden opdatering inden for de næste 30 minutter, eller før hvis mere information bliver tilgængelig.
resolved
Mellem ca. 15: 30 UTC og 20: 30 UTC den 6. oktober 2026 oplevede kunderne forsinkelser og svigt, der påvirkede rørledninger, arbejdsgange og arbejdspladser.
Fra ca. 16: 02 UTC til 16: 39 UTC var rørledninger svigtende, og ingen nye arbejdsgange eller job kunne starte. Efter service genoptaget, fortsatte arbejdsgange og job med at starte med forsinkelser indtil omkring 20: 00 UTC. Starttiderne var i gennemsnit op til ca. 40 minutter på deres højdepunkt, og et meget lille antal arbejdsgange ventede mere end 1 time. Udgående meddelelser og webkroge blev også forsinket til omkring 19: 00 UTC, typisk med omkring et minut.
Som efterslæbet af forsinket arbejde ryddet, den resulterende stigning i efterspørgslen lagt pres på vores udførelse kapacitet, forårsager yderligere forsinkelser for Docker og Linux job. Fra ca. 19: 45 UTC til 20: 30 UTC ventede disse job i køen længere end normalt, før de startede. På toppen, omkring 20: 05 UTC, venter nået op til ca. 8 minutter for 2xlarge gen2, 6 minutter for xlarge gen2, og mindre end 5 minutter for et par andre ressource klasser.
Problemet er løst, og alle berørte funktioner er vendt tilbage til normal. Kunder hvis job mislykkedes under dette vindue kan køre de berørte job igen. Vi takker dig for din tålmodighed, mens vores team arbejdede på at gennemføre et fix.
postmortem
# # Summary
Den 6. oktober 2026, fra 15: 30 til 20: 30 UTC, CircleCI kunder oplevede forsinkelser skabe rørledninger og starte arbejdsgange og job. Fra 15: 48 til 16: 38 UTC, ingen arbejdsgange eller job startet, og rørledninger udløst fra 16: 02 UTC mislykkedes. Kortere, intermitterende forsinkelser begyndte tidligere, kl 13: 30 UTC. Data i CircleCI UI, meddelelser og begå statusopdateringer til versionskontroludbydere blev også forsinket.
Hændelsen startede i databasen bag vores workflow orkestertjeneste, som koordinerer alle rørledninger, workflow og job på CircleCI. Rutinemæssig vedligeholdelse på databasens største tabeller skrev transaktionslogfiler hurtigere end databasen kunne arkivere dem, og loggene fyldte lagervolumen afsat til dem. For at holde databasen fra at blive read- kun, vores ingeniører flyttet logfiler til databasens vigtigste lagervolumen. Det tog databasen offline i 50 minutter. Da databasen kom tilbage, det behandlet arbejde på omkring halvdelen af sin normale sats indtil vores ingeniører ændret en database indstilling på 18: 19 UTC. Vi arbejdede derefter gennem backloggen, og job start tider vendte tilbage til normal ved 20: 30 UTC.
Kunder hvis job mislykkedes under dette vindue kan køre dem igen.
Den oprindelige statusside kan findes [her] (https: / / status.circleci.com / hændelser / z4hbq8h49j8c).
# Baggrund
Når du udløser en pipeline, giver CircleCI den til en workflow orkestertjeneste. Denne service sporer tilstanden af alle arbejdsgange og job, beslutter, hvornår hvert job er klar til at køre, og passerer klar job til vores udførelse flåde. Det driver også de jobdata, du ser i UI og meddelelser og forpligte statuer, vi sender, når arbejdet er færdigt.
Arrangøringstjenesten gemmer sin stat i en database. Databasen skriver hver ændring til en transaktionsjournal, før den anvendes, og det holder disse logfiler på en dedikeret lagervolumen. Det arkiverer logs kontinuerligt, så det kan genbruge det rum. Hvis arkivering falder bagud og volumen fylder, databasen stopper acceptere skriver, og intet nyt arbejde kan bevæge sig fremad.
Databasen kører også en periodisk vedligeholdelsesproces\ (autovacuums\) på hvert bord for at holde sine interne optegnelser gyldige over tid. På en meget stor tabel, denne proces læser hver side i tabellen og skriver en stor mængde af transaktioner logfiler.
Hvad skete der
_\ (Alle gange UTC\)
Fra 10: 02 den 6. oktober, vores overvågning rejst kortlivede advarsler om fejl i orkester tjeneste. Hver alarm er ryddet inden for 15 minutter. Vores ingeniører havde set lignende korte advarsler før, og systemet viste ingen andre tegn på stress, så de fulgte runbook hver gang, og hver alarm ryddet på sin egen delvej gennem og også begyndte at arbejde for at gøre varslingerne mindre følsomme.
Omkring 12: 40, sammen med den regelmæssige arbejdsbyrde, som genererer sine egne transaktionsjournaler, vedligeholdelsesprocessen på flere af databasens største tabeller begyndte at skrive yderligere transaktionsjournaler hurtigere end databasen kunne arkivere dem, og logvolumen begyndte at fylde.
Kl. 13.30 begyndte orkesterholdet at sætte farten ned. Gennem 15: 30 tog nogle rørledninger og job længere tid at starte, i korte brister. Kl. 13.35 alarmerede vores overvågning igen, denne gang sammen med relaterede indberetninger fra flere andre tjenester. Infrastrukturingeniører fulgte alarmbøgerne og ryddede nogle af alarmerne op. Advarslerne returnerede igen kl. 14.30, og efter at have undersøgt nærmere, erklærede vi en hændelse kl. 14.54. Vi burde have anerkendt kombinationen af advarsler tidligere, og vi har dækket, hvordan vi fastsætter det nedenfor.
Efter at have erklæret hændelsen, vores ingeniører sporet afmatningen til vedligeholdelsesprocessen\ (anti-wrapround autovacuum\). Databasen genstarter automatisk denne proces, hvis den er aflyst, så vores ingeniører ændrede sine indstillinger for at hjælpe den med at afslutte hurtigere. Ved 15: 30, forsinkelserne var vedvarende, og nogle job begyndte at mislykkes.
Kl. 15: 43 var transaktionslogbogen næsten fuld. Hvis det fyldte, ville databasen stoppe med at acceptere skrifter og intet arbejde kunne køre. Vores ingeniører besluttede at flytte transaktionen logs på databasens vigtigste lagervolumen, som havde masser af ledig plads. Flytningen krævede databasen til at gå offline, og vi kunne ikke forudsige på forhånd, hvor lang tid det ville tage.
Flytningen startede kl. 15.47. Fra 15: 48 til 16: 38 kunne orkestertjenesten ikke bearbejde noget arbejde. Kunderne kunne stadig udløse rørledninger, men ingen arbejdsgange eller job startede, og fra 16: 02 nyudløste rørledninger mislykkedes. Vi posted til vores status side på 15: 58 og rejst det til en større udfald på 16: 20. Mens databasen var offline, lavede vores ingeniører en erstatningsdatabase som en fallback. Den oprindelige database kom tilbage først, så vi holdt den i brug.
Klokken 16.38 kom databasen tilbage online, og arbejdet begyndte at flyde igen. Med transaktionsjournaler og regelmæssige data nu deler den samme opbevaring, databasen kørte langsommere end før. Fra 16: 38 til 18: 19 behandlede orkestertjenesten arbejdet med ca. halvdelen af sin normale hastighed, og arbejdspladserne ventede ti minutter på at starte, op til omkring 50 minutter på den længste. I løbet af den tid, databasen var nødt til at afslutte arkivering sin backlog af transaktionsjournaler, før vi kunne flytte dem tilbage til en dedikeret volumen. Vi har også undersøgt og implementeret flere databasemarametre ændringer for at stoppe yderligere vedligeholdelse kører fra start og forberedt måder at reducere arbejdet når tjenesten. Sammen med den udskiftning database, vi også forberedt en komplet stak af tjenesten i løbet af den tid, så vi kunne flytte til det med risiko for tab af data og valgt imod dette træk.
Kl. 18: 19 ændrede vores ingeniører en databaseindstilling for at skære den tid, hver skrivning brugte på opbevaring. Processing hastighed genvundet, og efterslæbet begyndte at rydde. For at rydde det hurtigere, vi tilføjet database og server kapacitet til de systemer, der hånd job til vores udførelse flåde. Omkring 19: 55 begyndte nye job igen til tiden.
Baggrunden nåede så vores henrettelse flåde. Fra 19: 49 til 20: 30, nogle Docker job på større ressource klasser ventede op til omkring 10 minutter til at starte, mens kapaciteten skaleret op. Ved 20: 30 var jobstart igen normal. Vi flyttede statussiden til overvågning kl. 20.32 og løste hændelsen kl. 21.19.
Omkring 3.500 job mislykkedes at starte under hændelsen. Kunder kan gendrive disse job. Vi fandt ingen beviser på, at CircleCI havde et job mere end én gang. Kunder, der genkørte et workflow, mens det oprindelige løb var stadig forsinket, kan have set begge kører komplet. Årlige plan kunder kan arbejde med deres konto team til at gennemgå brugen.
# Fremtidig forebyggelse og procesforbedring
Vi tager følgende skridt for at forhindre en gentagelse og forbedre vores responstid:
* * Vi tilføjer advarsler om de betingelser, der forårsagede denne hændelse. * * Vores overvågning fangede afmatningen, men vi havde ingen advarsel om, hvor fuld transaktionen log volumen var, eller hvor langt arkivering var faldet bagud. Vi tilføjer advarsler om begge, sammen med advarsler om den database vedligeholdelse, der driver dem, så vi kan handle tidligere. Vi er også på besøg alle vores advarsler for at sikre støjende eller følsomme advarsler ikke skjule reelle spørgsmål.
* * Vi justerer hvordan vedligeholdelsesprocessen\ (autovakuum\) kører på vores database. * * Vi ser på den frekvens og aggressivitet, hvormed autovakuums kører på vores database. Vi sporer også størrelsen af disse borde over tid, så de holder sig inden for sikre grænser.
* * Vi fjerner den enkelte transaktion log flaskehals. * * Alle de orkestrerende tjenesters skrifter går i øjeblikket gennem en database og en transaktionsjournal, så når denne log faldt bagud, hver rørledning, workflow og job bremset med det. Vi er ved at evaluere to tilgange: opdele tjenesten på tværs af flere database instanser, hver med sin egen transaktionsjournal, og flytte det til en distribueret database bygget til at sprede skriver på tværs af mange knudepunkter. Begge metoder ville begrænse virkningen af en forsinkelse til en del af arbejdsbyrden.
* * Vi får vores systemer til at vente på, at orkestertjenesten kommer sig. * * Under hændelsen fejlede nogle job, fordi vores systemer gav op efter at have forsøgt igen. Vi arbejder på at ændre den adfærd.
* * Vi forbedrer vores status side opdateringer under lange hændelser. * * Kunder fortalte os vores tidlige opdateringer ikke give nok detaljer. Vi opdaterer vores vejledning, så opdateringer inkluderer specifik effekt og timing før.
Name
Kundeoplevelsen er vores topprioritet, og vi forpligter os til løbende at forbedre pålideligheden af vores systemer til at matche den tillid, som vores kunder lægger i os. Vi takker vores kunder for deres tålmodighed, mens vores team arbejdede for at løse denne hændelse. Kontakt vores supporthold med spørgsmål eller bekymringer.
Automatisk oversat fra den officielle hændelsesopdatering.
Forsinkelser starter Gen 2 Docker Jobs
Startede 1. oktober 2026 kl. 09.06 UTC · 1h 39m
IssuesMindre hændelse
Berørte komponenter
Docker Jobs
investigating
Kunder kan opleve forsinkelser i starten af Docker Gen 2 Jobs. Vi arbejder på at øge systemets kapacitet for at opnå dette.
identified
Vi har identificeret årsagen, og vi arbejder aktivt på et fix. Tak for din tålmodighed.
identified
Et fix er blevet rullet ud, og vi er begyndt at observere helbredelse.
monitoring
Vi ser kø gange vende tilbage til normale niveauer, og fortsætter med at overvåge.
resolved
Denne hændelse er blevet løst.
postmortem
# * * Oversigt * *
Mellem den 1. oktober og den 8. oktober 2026 oplevede CircleCI-kunderne fem separate hændelser, hvor job ventede længere end normalt for at starte eller ikke startede. Tre af hændelserne blev drevet af begrænsede eksempler tilgængelighed fra vores cloud-udbyder. En var forårsaget af et konfigurationsproblem i vores planlægning infrastruktur, og en af hukommelsesbegrænsninger på en intern tjeneste, som vi rejste under hændelsen.
* * * Oktober 1, 07: 57 til 10: 24 UTC: * * Docker Gen 2 job ventede op til 30 minutter til at starte. Et konfigurationsproblem forhindrede Gen 2-planlægningsserverne i at bruge deres højtydende lokale diske. Under et udbrud i trafikken, faldt fallback disketterne mættet og jobplacering langsommere.
* * * 7. oktober, 13: 27 til 14: 06 UTC: * * Machine job ventede længere end normalt, fordi vi ikke kunne erhverve nok virtuelle maskiner fra vores cloud udbyder.
* * * 7. oktober, 14: 24 til 15: 21 UTC: * * Nogle job mislykkedes med en infrastrukturfejl, og arbejdsgange blev forsinket. Den service, der giver hvert job sin konfiguration ved opstart løb tør for hukommelse og genstartet.
* * * 7. oktober 18: 49 til 20: 05 UTC: * * Docker Gen 2 job ventede længere end normalt, fordi vi ikke kunne erhverve nok tilfælde fra vores cloud udbyder.
* * * 8. oktober, 12: 48 til 16: 00 UTC: * * Linux maskine job og fjernbetjening Docker job ventede op til 50 minutter til at starte. Vores cloud-udbyder havde ikke nok af den instans type, vi anmoder om, og en fejl i logikken, der vælger en anden instans type afholdt os fra at bruge alternativer.
Jobs, der ventede under disse hændelser blev forsinket, ikke tabt. Kunder, hvis job mislykkedes med en infrastrukturfejl i oktober 7 hændelsen fra 14: 24 til 15: 21 UTC kan genkøre dem.
De oprindelige statussider kan findes nedenfor:
[1. oktober - Forsinkelser ved start af Gen 2 Docker Jobs] (https: / / status.circleci.com / hændelser / 22mrv46g6n7g)
* [7. oktober - Forsinkelse på start Machine Job Opgaver] (https: / / status.circleci.com / hændelser / tj6wdnfjwr64)
* [7. oktober - Forhøjet niveau af infraa mislykkes på kundejob] (https: / / status.circleci.com / hændelser / 0z31ldjd8m5v)
[7. oktober - Øget ventetid for Docker Gen2] (https: / / status.circleci.com / hændelser / 39rfrjmk5pvd)
* [8. oktober - Forhøjede ventetider for maskinjob] (https: / / status.circleci.com / hændelser / jn756xtsy4xg)
# * * Baggrund * *
Hvert job, der kører på CircleCI skal beregnes. Hvor denne beregning kommer fra afhænger af eksekutor.
Docker job kører på klynger af servere, der tidsplan arbejde på en flåde af tilfælde. Scheduler er software på de servere, der beslutter, hvilken instans kører hvert job. Gen 2 Docker job kørte på en sådan klynge på tidspunktet for oktober 1 hændelse. Gen 1 Docker job er spredt over flere klynger.
Machine job, herunder fjernbetjening Docker job, få en dedikeret virtuel maskine. En remote Docker job håndteres som en Linux-maskine job fra indsendelse gennem levering. Vores maskine levering service anmoder hver maskine fra vores cloud-udbyder i en af de to regioner, vi normalt bruger til maskine job. Når udbyderen ikke kan levere den instans type, vi anmoder om, tjenesten falder tilbage: det kræver en anden instans type, eller en anden region, fra en liste, vi vedligeholder. Et job venter, indtil en maskine er tilgængelig.
Når et job starter, beder det en jobkonfigurationstjeneste om dets konfiguration. Denne tjeneste kører som et sæt kapsler, som er små kopier af det samme program. Hvis for mange kapsler stopper, bærer de resterende kapsler mere last, og job kan ikke starte, før tjenesten kommer sig.
Disse stier afhænger af tre slags kapacitet: gennemløbet af vores planlægningssystemer, levering af instanser fra vores cloud-udbyder, og hukommelse og antal kopier af de tjenester, der starter job. En mangel på nogen af dem gør job vente eller mislykkes.
Hvad skete der?
_\ (Alle gange UTC\)
# # # * * Oktober 1: Docker Gen 2 job forsinket op til 30 minutter * *
Kl. 07: 44 steg diskaktiviteten på de servere, der planlagde Gen 2 Docker job til 90% af kapaciteten og blev der. Kl. 07: 57 begyndte antallet af Docker-job at vokse, og ventetiden steg med det. En automatisk alarm tilkaldte on- call ingeniør kl 08: 08. Vi erklærede en hændelse kl. 08: 42.
Kl. 08: 43 identificerede ingeniørerne highdisk latency på planlægningsserverne. De første troede diskene var for langsom til belastningen, så de forberedte en ændring til en hurtigere disk type. Kl. 09: 01 blev holdet enige om to arbejdsstrømme: flytte serverne til hurtigere diske, og tilføje en anden Gen 2 klynge, så job ville splitte på tværs af to klynger.
Kl. 09: 41 fandt ingeniører årsagen. Hver planlægning server har hurtige diske knyttet direkte til det, og scheduler er beregnet til at holde sine arbejdsdata der. Disse servere kører på en security- hærdet styresystem billede, og på dette billede de hurtige diske blev ikke brugt. Scheduler skrev sine data til langsommere netværksforbundne diske i stedet. Scriptet, der opsætter de hurtige diske mislykkedes uden en fejl, og et hul i logning på disse servere skjulte fejlen. Gen 2-trafikken var også blevet mere og mere eksplosiv. De langsommere diske mættet under disse sprængninger, og scheduler faldt bagud.
Ventetider toppede kl 09: 54, da job på Gen 2 medium ressource klasse ventede op til 30 minutter. Kl. 09: 55 anvendte ingeniører et fix, der satte de hurtige diske op korrekt. Kl. 10: 11 begyndte scheduler at placere job hurtigere, hvilket bekræftede serverne kunne holde trit med nye job. Ventetider for Gen 2 medium faldt til 13 minutter ved 10: 14, 7 minutter ved 10: 17, og 1 minut 30 sekunder ved 10: 20. Vi flyttede statussiden til overvågning kl. 10.24 og løste hændelsen kl. 10.45.
Kl. 11.20 begyndte den anden Gen 2-klynge at drive job.
# # # * * 7. oktober 13: 27 til 14: 06: Forhøjede ventetider for maskinjobs * *
Vi erklærede en hændelse kl 13: 27 efter at have set forhøjet kø og ventetider. Vi skrev til status side på 13: 31. Kl. 13: 31 så ingeniører, at vi kæmpede for at erhverve virtuelle maskiner til maskinjob, og at antallet af job, der ventede på at starte, var højt primært for maskinjob. Kl. 13.34 blev ventetiden hævet på tværs af eksekutorerne.
kl. 13.48 begyndte ventetiden at komme sig, da flere maskiner blev tilgængelige, og vi løste hændelsen kl. 14.06.
# # # * * 7. oktober, 14: 24 til 15: 21: Jobsvigt og forsinkelser i arbejdsgangen * *
Kort efter den forrige hændelse var markeret som løst, erklærede vi en ny hændelse kl. 14: 24 på grund af et kraftigt fald i antallet af job, der blev indsendt til vores gennemførelsessystemer. Kl. 14: 26 så ingeniører, at kapslerne fra jobkonfigurationstjenesten var ved at starte forfra. Pods, der genstarter efterlader færre kopier af tjenesten til at besvare anmodninger, og job, der ikke kunne hente deres konfiguration efter gentagne forsøg mislykkedes med en infrastrukturfejl. Arbejdsgange, der allerede kørte ventede på opdateringer fra job, der ikke var startet.
Kl. 14.35 øgede ingeniørerne mængden af tilgængelig hukommelse til kapslerne og øgede antallet af kapsler, hvilket gav tjenesten flere kopier til at dele byrden. Vi har også øget mængden af hukommelse tilgængelige Job indlæg begyndte at komme sig, og antallet af beskeder flyder gennem vores workflow system vendte tilbage til normale niveauer. Kl. 14.44 flyttede vi statussiden til overvågning.
Pods i jobkonfiguration service nåede deres hukommelse grænser og genstartet. Vi øgede hukommelsen og pod tæller, og tjenesten kom sig. Kl. 15: 13 øgede vi antallet af tilfælde i vores Gen 2 Docker-klynger, så vi hurtigt kunne arbejde os igennem en ophobning af ventende job. Vi løste hændelsen kl. 15: 21.
# # # * * 7. oktober 18: 49 til 20: 05: Forhøjede ventetider for Docker Gen 2 jobs * *
Vi erklærede en ny hændelse kl 18: 49 efter Docker Gen 2 ventetider steg. Kl. 18: 51 bekræftede ingeniører, at mangel på tilgængelige tilfælde forhindrede os i at erhverve nok af dem, som hævede ventetider. Ventetider afveg efter ressourceklassestørrelse.
kl 19: 52, gennemsnitlige ventetider var lavere end en time tidligere som mere kapacitet blev til rådighed, selvom korte pigge fortsatte, og vi flyttede status side til overvågning. Vi løste hændelsen kl. 20.05.
# # # * * 8. oktober: Linux-maskine og eksterne Docker job venter op til 50 minutter * *
Vi erklærede en hændelse kl 12: 48 efter at have set et stort antal job venter på at starte og lange ventetider for maskine og fjernbetjening Docker job. Kl. 12: 49 så ingeniører, at vores cloud-udbyder ikke kunne levere nok tilfælde. Forsinkelser fortsatte med at klatre som vi undersøgte.
Kl. 13: 13 begyndte vi at undersøge logikken, der vælger en anden instans type eller region, når vores første valg er utilgængelig. Kl. 13: 24 havde vi mistanke om, at en fejl i denne logik forhindrede os i at bruge andre eksempler i vores primære region, så vi deaktiverede vores fallback-region og bekræftede årsagen til fejlen. Ingeniører begyndte at arbejde på et fix og indsat det på 14: 49. Tjenesten begyndte at anmode om andre eksempler typer og startede maskiner i stort antal. Kl. 14.58 faldt antallet af jobs, der ventede på en maskine, støt. Gennemsnitlige ventetider på tværs af ressourceklasser fortsatte med at falde i løbet af den næste time, da vi arbejdede gennem backlog af ventende job.
kl. 16: 00, køen af job venter på en maskine ryddet og antallet af ventende job tilbage til normal. Vi flyttede statussiden til overvågning kl. 16.09 og løste hændelsen kl. 16.35.
# # * * Fremtidig forebyggelse og procesforbedring * *
Vi tager følgende skridt til at styrke modstandsdygtigheden i jobstarttider, herunder diversificering af udbuddet, fallback-logik og tidligere opdagelse.
* * Vi udvider vores computerregioner. * * I den 7. oktober og 8. oktober kunne vores cloud-udbyder ikke levere nok tilfælde i de regioner, vi brugte. Vi tilføjer nye regioner til vores fallback-logik for at håndtere stigninger i efterspørgslen, der overstiger vores foretrukne regioner.
* * Vi er ved at fastsætte den logik, der vælger en anden instans type. * * Den 8. oktober forhindrede en defekt, at maskinereservatoren brugte andre typer af cases i samme region. Vi har indsat en rettelse under hændelsen og er nu at gennemgå og refaktorere denne logik som helhed, med tests, så en mangel på en instans type flytter arbejde til en anden.
* * Vi udvider de eksempler typer, vi tilbyder og sikrer ekstra kapacitet. * * Vi samarbejder med vores cloud-udbyder om at reservere ekstra kapacitet i vores eksisterende regioner, og vi tilføjer eksempler typer, som job kan køre på. Industriens efterspørgsel efter højtydende beregninger er stigende. Vi diversificerer hvor og hvordan vi leverer kapacitet, så vores kunder er isoleret fra forsyningsvariationen.
* * Vi tilføjede en anden Gen 2 Docker klynge så trafik sprængninger er fordelt på to klynger. * * Vi tilføjer også advarsler om planlægning server disk mætning og om, hvor hurtigt scheduler placerer job, og en alarm, der skyder, når en server starter uden sine hurtige diske i brug. Vi gjorde disk setup script mislykkes med en fejl, og vi restaurerede log forsendelse fra disse servere, så et lignende problem er synlig før.
Kundeoplevelsen er vores topprioritet, og vi forpligter os til løbende at forbedre pålideligheden af vores systemer til at matche den tillid, som vores kunder lægger i os. Vi takker vores kunder for deres tålmodighed, mens vores team arbejdede for at løse disse hændelser. Kontakt vores supporthold med spørgsmål eller bekymringer.
Automatisk oversat fra den officielle hændelsesopdatering.
Forsinkelser i behandlingen af nye tilmeldinger og planændringer
Startede 23. september 2026 kl. 18.13 UTC · 1h 53m
Pending
Berørte komponenter
Billing & Account
identified
Kunderne kan opleve forsinkelser i nye tilmeldinger og planændringer afspejles i deres konto.
resolved
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
Forsinkelser starter Linux Machine job
Startede 21. september 2026 kl. 16.22 UTC · 47m
IssuesMindre hændelse
Berørte komponenter
Machine Jobs
investigating
Kunder kan opleve forsinkelser i starten af job på Linux Machine. Vi efterforsker det.
monitoring
Opgave ventetider for Linux Machine vender tilbage til normal.
resolved
This incident has been resolved.
Automatisk oversat fra den officielle hændelsesopdatering.
Kunder kan opleve forsinkelser i UI opdateringer
Startede 16. september 2026 kl. 14.55 UTC · 4h 35m
IssuesMindre hændelse
Berørte komponenter
CircleCI APICircleCI UI
investigating
Vi er ved at undersøge en forsinkelse i udviklingen af rørlednings data. Pipelines kører stadig, men data om dem kan blive forsinket i UI eller API.
identified
Vi har identificeret problemet og arbejder på en oprydning. Tak for din tålmodighed.
identified
Pipeline data er nu tilgængelige som normalt, med undtagelse af testresultater, som stadig kan blive forsinket. Vi arbejder videre med dette, tak for Deres tålmodighed.
monitoring
Alle rørlednings data er nu tilgængelige som normalt. Vi vil fortsat overvåge opsvinget.
resolved
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
Kunder kan opleve forsinkelser i UI opdateringer
Startede 15. september 2026 kl. 14.42 UTC · 2h 20m
IssuesMindre hændelse
Berørte komponenter
CircleCI UI
investigating
Vi ser i øjeblikket en forsinkelse i rørledningens data, der dukker op i EU.
identified
Vi begynder at se noget bedring.
resolved
Hændelsen, der påvirker rørledningens data i EU-erhvervsgrenen, er nu blevet løst. Vi takker dig for din tålmodighed, mens vores ingeniører arbejdede på at reducere forsinkelserne.
Automatisk oversat fra den officielle hændelsesopdatering.
Øget ventetid for macOS job
Startede 14. september 2026 kl. 11.59 UTC · 1h 0m
IssuesMindre hændelse
Berørte komponenter
macOS Jobs
investigating
På grund af øgede netværksfejl og latesser ser vi øgede ventetider for macOS job. Vi undersøger dette med vores macOS hosting udbyder.
investigating
Ventetider for macOS job er faldende, og vi fortsætter med at undersøge.
monitoring
Vores macOS hosting udbyder har gennemført en afbødning, og vi har set bedre latesser. Vi vil fortsat overvåge.
resolved
Ventetider for MacOS job er tilbage til normal.
Automatisk oversat fra den officielle hændelsesopdatering.
Spørgsmål om at læsse rørledninger til et lille antal projekter
Startede 10. september 2026 kl. 20.25 UTC · 1m
IssuesMindre hændelse
Berørte komponenter
CircleCI UI
identified
Et lille antal kunder kan se fejl eller være ude af stand til at indlæse rørledninger side for projekter med despecicated- config advarsler, når du bruger den klassiske rørledninger visning. Kunder i den nye rørledningsvisning påvirkes ikke. Vi har identificeret årsagen og sat et fix ind.
monitoring
Et fix er blevet gennemført, og vi overvåger resultaterne.
resolved
Denne hændelse er blevet løst. Et lille antal kunder, der skabte rørledninger mellem 18: 53 UTC og 19: 24 UTC, der indeholdt config ved hjælp af forældet config syntaks vil have set deres bygge-type job ikke at starte. Kunder, hvis job eller rørledninger mislykkedes, kan gendrive dem.
Automatisk oversat fra den officielle hændelsesopdatering.
macOS Job Delays
Startede 4. september 2026 kl. 15.16 UTC · 1h 40m
IssuesMindre hændelse
Berørte komponenter
macOS Jobs
investigating
Vi har opdaget netværksproblemer, der påvirker vores Mac infrastruktur. Vi efterforsker og vil levere opdateringer snart. Kunder kan opleve kø i løbet af denne tid.
identified
Vi har identificeret netværksproblemet med vores Mac infrastruktur udbyder, og arbejder med dem for at løse problemet. Vi begynder at se noget bedring, men vi forventer kunder kan stadig se nogle kø. Vi opdaterer igen om lidt.
monitoring
Vores Mac infrastruktur udbyder har anvendt en rettelse til dette netværk problem, og vi ser kø gange vende tilbage til normal. Vi fortsætter med at holde øje med tingene lidt længere. Vi opdaterer igen om lidt.
resolved
Vi har ikke set flere slag til køerne, og alt er blevet normalt igen. Vi sætter pris på Deres tålmodighed, mens vi arbejdede på at løse og overvåge dette spørgsmål.
Automatisk oversat fra den officielle hændelsesopdatering.
Intermitterende fejl ved visning af brugen af planen UI 'er eller kalde brug af planen API' er
Startede 26. august 2026 kl. 15.43 UTC · 27m
IssuesMindre hændelse
Berørte komponenter
CircleCI APICircleCI UI
identified
Kunderne kan opleve periodiske fejl, når du ser planen brug UI 'er eller kalder planen brug API' er. Vi har identificeret problemet, og vi arbejder aktivt på at afhjælpe disse fejl.
monitoring
Vi har mindsket problemet med planen brug API 'er og de relevante sider i UI' en indlæses korrekt.
resolved
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
GitHub Login Disruption
Startede 25. august 2026 kl. 20.00 UTC · 0m
IssuesMindre hændelse
resolved
Mellem 19: 49 UTC og 21: 07 UTC den 25. august 2026, kunder forsøger at logge ind på CircleCI ved hjælp af GitHub var ude af stand til at logge ind, og modtog en fejl fra GitHub angiver callback URL var ugyldig. Kunder, der allerede var logget ind, blev ikke påvirket. Problemet er blevet løst, og GitHub login fungerer normalt. Vi takker dig for din tålmodighed, mens vores team arbejdede på at gennemføre et fix.
Automatisk oversat fra den officielle hændelsesopdatering.
Indsigt data er i øjeblikket forsinket
Startede 17. august 2026 kl. 21.06 UTC · 31m
IssuesMindre hændelse
Berørte komponenter
CircleCI Insights
identified
Årsagen til spørgsmålet er blevet identificeret, og vi er på arbejde med at løse det.
monitoring
Et fix er blevet gennemført, og vi overvåger resultaterne.
resolved
Indsigt data er godt igen. Tak for din tålmodighed.
Automatisk oversat fra den officielle hændelsesopdatering.
