Historia awarii Circle Ci

1. 4 września 2026 15:16 UTCinvestigating

   Wykryliśmy problemy sieciowe wpływające na naszą infrastrukturę Mac. Prowadzimy śledztwo i wkrótce dostarczymy nowe informacje. Klienci mogą doświadczyć kolejki w tym czasie.

2. 4 września 2026 15:43 UTCidentified

   Zidentyfikowaliśmy problem sieciowy z naszym dostawcą infrastruktury Mac i pracujemy z nimi nad rozwiązaniem problemu. Zaczynamy dostrzegać poprawę, ale spodziewamy się, że klienci nadal mogą zobaczyć kolejkę. Niedługo się dowiemy.

3. 4 września 2026 16:19 UTCmonitoring

   Nasz dostawca infrastruktury Mac zastosował rozwiązanie tego problemu sieciowego i widzimy, że czas kolejki wraca do normy. Będziemy mieć oko na sprawy jeszcze przez jakiś czas. Niedługo się dowiemy.

4. 4 września 2026 16:55 UTCresolved

   Nie widzieliśmy żadnego wpływu na kolejkę i wszystko wróciło do normy. Doceniamy waszą cierpliwość, pracując nad rozwiązaniem i monitorowaniem tej kwestii.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 26 sierpnia 2026 15:43 UTCidentified

   Klienci mogą doświadczać błędów przerywanych podczas przeglądania wykorzystania planów UI lub korzystania z API planu wywołania. Zidentyfikowaliśmy tę kwestię i aktywnie pracujemy nad złagodzeniem tych błędów.

2. 26 sierpnia 2026 16:04 UTCmonitoring

   Zminimalizowaliśmy problem z wykorzystaniem API planu i odpowiednie strony w UI ładują poprawnie.

3. 26 sierpnia 2026 16:10 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 25 sierpnia 2026 23:20 UTCresolved

   Między 19: 49 UTC a 21: 07 UTC w dniu 25 sierpnia 2026 roku, klienci próbujący zalogować się do CircleCI za pomocą GitHub nie byli w stanie się zalogować i otrzymali od GitHub błąd stwierdzający, że adres URL jest nieprawidłowy. Klienci, którzy już się zalogowali, nie ucierpieli. Problem został rozwiązany i GitHub logowanie działa normalnie. Dziękujemy za cierpliwość, podczas gdy nasz zespół pracował nad wdrożeniem poprawki.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 17 sierpnia 2026 21:06 UTCidentified

   Zidentyfikowano przyczynę problemu i jesteśmy w trakcie prac nad jego naprawą.

2. 17 sierpnia 2026 21:36 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 17 sierpnia 2026 21:37 UTCresolved

   Dane z obserwacji są dobre jeszcze raz. Dziękuję za cierpliwość.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 17 sierpnia 2026 14:04 UTCidentified

   GitHub zgłosił incydent, który wpływa na uruchomienie i wylogowanie rurociągu CircleCI: https: / / www.githubstatus.com / invents / zkxwbgr0cnmx Roboty, które są w lotach są uruchomione, ale status zgłaszania do GitHub Pull Requests może się nie udać.

2. 17 sierpnia 2026 14:25 UTCidentified

   Nadal obserwujemy wysokie poziomy błędów w API GitHub i zmniejszony ruch haka. Będziemy nadal dostarczać aktualizacje w miarę dostępności większej ilości informacji.

3. 17 sierpnia 2026 15:49 UTCidentified

   Nadal obserwujemy wysoki poziom błędów w API GitHuba i zmniejszony ruch haka. Klienci wykorzystujący GitHub jako swój system VCS mogą odczuwać wpływ na swoje doświadczenie platformy CircleCI. Jest to bezpośrednio związane z incydentem, którego doświadcza GitHub: https: / / www.githubstatus.com / invents / zkxwbgr0cnmx Dostarczymy aktualizacje w miarę dostępności większej ilości informacji.

4. 17 sierpnia 2026 16:22 UTCmonitoring

   Zaczęliśmy obserwować poprawę stabilności w API GitHub. Będziemy monitorować ich stan.

5. 17 sierpnia 2026 17:01 UTCmonitoring

   Wskaźniki błędów i opóźnień API GitHub wydają się odzyskać. Będziemy nadal monitorować.

6. 17 sierpnia 2026 17:23 UTCmonitoring

   Niektóre API GitHuba są nadal zdegradowane, co prowadzi do niewielkiej liczby błędów związanych z aktualizacjami statusu i przetwarzaniem haczyków. Będziemy nadal dokładać wszelkich starań, aby złagodzić te skutki.

7. 17 sierpnia 2026 19:05 UTCresolved

   API GitHuba działają normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 15 sierpnia 2026 13:58 UTCresolved

   Po planowanej konserwacji, która zakończyła się o 13: 00 UTC 15 sierpnia, pewien wpływ na przetwarzanie pracy trwał około 30 minut poza oknem, które ogłosiliśmy. Niektórzy klienci nadal obserwowali opóźnienia w zatrudnieniu, wraz z niewielką liczbą miejsc pracy, które nie powiodły się z błędami w infrastrukturze, do około 13: 30 UTC. Zostało to rozwiązane, a przetwarzanie pracy wróciło do normy. Klienci, których praca nie powiodła się w tym oknie, mogą wznowić pracę. Dziękujemy za cierpliwość, podczas gdy nasz zespół pracował nad wdrożeniem poprawki i przeprosić za wszelkie niedogodności, które mógł spowodować rozszerzony wpływ.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 12 sierpnia 2026 16:33 UTCidentified

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

2. 12 sierpnia 2026 16:43 UTCresolved

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

1. 11 sierpnia 2026 17:42 UTCresolved

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

1. 6 sierpnia 2026 13:06 UTCinvestigating

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

2. 6 sierpnia 2026 15:06 UTCidentified

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

3. 6 sierpnia 2026 19:33 UTCmonitoring

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

4. 6 sierpnia 2026 19:54 UTCresolved

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

1. 5 sierpnia 2026 16:58 UTCinvestigating

   Widzimy problem z usługą Insights, gdzie dane z ostatnich 24 godzin są opóźnione. Prowadzimy śledztwo.

2. 5 sierpnia 2026 17:46 UTCinvestigating

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

3. 5 sierpnia 2026 18:25 UTCidentified

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

4. 5 sierpnia 2026 21:01 UTCresolved

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

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 4 sierpnia 2026 19:27 UTCinvestigating

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

2. 4 sierpnia 2026 19:59 UTCmonitoring

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

3. 4 sierpnia 2026 20:33 UTCmonitoring

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

4. 4 sierpnia 2026 21:16 UTCmonitoring

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

5. 4 sierpnia 2026 21:46 UTCmonitoring

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

6. 4 sierpnia 2026 22:20 UTCmonitoring

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

7. 4 sierpnia 2026 23:40 UTCresolved

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

1. 24 lipca 2026 16:35 UTCidentified

   GitHub doświadcza obecnie degradacji usług (https: / / www.githubstatus.com / invents / yjysg0xrl67m). Klienci, którzy korzystają z GitHub jako ich VCS mogą mieć wpływ na swoje doświadczenie platformy CircleCI w wyniku, wpływając na checkout i przepływów pracy. Dostarczymy kolejną aktualizację, ponieważ mamy więcej informacji do przekazania. Dziękuję za cierpliwość.

2. 24 lipca 2026 17:41 UTCresolved

   Sprawa wpływająca na klientów, którzy wykorzystują GitHub jako swój VCS, podczas gdy GitHub był poddawany degradacji usług (https: / / www.githubstatus.com / invents / yjysg0xrl67m), została już rozwiązana. GitHub rozwiązał podstawowy problem, a jego funkcjonalność wróciła do normy. Dziękujemy za cierpliwość.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 22 lipca 2026 19:57 UTCinvestigating

   Prowadzimy śledztwo w sprawie opóźnień w rozpoczęciu pracy przy użyciu klasy zasobów gen3.

2. 22 lipca 2026 23:17 UTCinvestigating

   Nadal badamy podwyższony czas oczekiwania, który wpływa na klientów wykorzystujących maszyny gen3. Rozpoczęcie pracy może trwać dłużej niż zwykle. Dostarczymy kolejną aktualizację, jak tylko będziemy mieli więcej informacji do przekazania.

3. 23 lipca 2026 00:31 UTCinvestigating

   Zidentyfikowaliśmy problem i współpracujemy z naszym dostawcą w celu rozwiązania problemu dostępności zasobów gen3. Gen 1 i Gen 2 są w pełni sprawne.

4. 23 lipca 2026 02:05 UTCresolved

   Między 19: 24 UTC w dniu 22 lipca a 01: 50 UTC w dniu 23 lipca, klienci korzystający z podglądu gen3 (Linux VM) klasy zasobów doświadczyli opóźnień i, w niektórych przypadkach, braku pracy. Usunęliśmy klasy zasobów gen3, zajmując się jednocześnie kwestiami stabilności, które ich dotyczą. Niestety, przepływy pracy, na które w tym okresie nie mogliśmy liczyć, zostały anulowane. Dotknięci klienci powinni zmienić swoją klasę zasobów z gen3 na gen2 i ponownie uruchomić te przepływy pracy. Dziękujemy za cierpliwość, podczas gdy nasz zespół pracował nad rozwiązaniem tego problemu.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 22 lipca 2026 06:13 UTCmonitoring

   Podzbiór klientów mógł doświadczyć błędów w załadowaniu app.circleci.com począwszy od 03: 18 UTC. Namierzono go, a my monitorujemy pełną rekonwalescencję. Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie potwierdzają powrót do zdrowia. Wkrótce dostarczymy kolejną aktualizację.

2. 22 lipca 2026 06:27 UTCresolved

   Między 03: 18 UTC a 06: 04 UTC w dniu 22 lipca 2026 r. podgrupa klientów nie była w stanie uzyskać dostępu do app.circleci.com. Problem został rozwiązany i dostęp powrócił do normy. Dziękujemy za cierpliwość, podczas gdy nasz zespół pracował nad wdrożeniem poprawki.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 lipca 2026 00:35 UTCidentified

   Zidentyfikowaliśmy problem z żądaniami GitHub API, który może spowodować, że niektórzy klienci zobaczą, że przepływy pracy utknęły w stanie pracy lub nie zaczynają się. GitHub zgłosił incydenty w API https: / / www.githubstatus.com / invents / ph5nns5y4gxj https: / / www.githubstatus.com / invents / 8vfyvq16hzh9 Monitorujemy stabilność API GitHub i będziemy aktualizować tę stronę, jak więcej informacji jest dostępnych.

2. 20 lipca 2026 01:24 UTCidentified

   Widzimy również błędy przetwarzania webhacks event push ze względu na awarię API. Użytkownicy mogą potrzebować ponownie spróbować rurociągów dla tych wydarzeń push.

3. 20 lipca 2026 01:36 UTCmonitoring

   Widzimy oznaki wyzdrowienia z GitHub API. Pozostaniemy w stanie monitorowania, aby sprawdzić, czy poziom błędu API odzyskał się.

4. 20 lipca 2026 01:45 UTCresolved

   Wskaźniki błędów GitHub API wróciły do normalnego poziomu. Podczas incydentu niektórzy klienci mogli widzieć, że rurociągi nie zaczynają lub nie otrzymują aktualizacji statusu. Niektóre rurociągi mogą utknąć w stanie ciągłym. * Należy ponownie nacisnąć commits lub użyć interfejsu użytkownika do ręcznego uruchamiania rurociągów, które nie rozpoczęły. * Rurociągi w zaciętym stanie należy anulować i ponownie uruchomić. Jeśli napotkasz jakiekolwiek problemy, skontaktuj się ze wsparciem CircleCI.

5. 23 lipca 2026 21:10 UTCpostmortem

   Podsumowanie W dniu 20 lipca 2026 od 00: 22 do 01: 45 UTC klienci CircleCI korzystający z naszej integracji GitHub doświadczyli niepowodzeń w prowadzeniu rurociągów i doświadczonych przepływów pracy utknęły. Podczas tego incydentu, niektóre rurociągi uruchomione przez użytkowników korzystających z GitHub nie uruchomiły się lub uruchomiły jako rurociągi błędów. Klienci, których rurociągi zawiodły lub przebiegły jako rurociągi błędów podczas tego okna, powinni je ponownie uruchomić. W związku z tym Komisja uznała, że nie można uznać, iż w przypadku braku pomocy państwa w rozumieniu art. 107 ust. 1 TFUE można uznać, że pomoc państwa nie jest zgodna z rynkiem wewnętrznym. Do 01: 45 UTC, GitHub API odzyskane, i gazociągi klientów działał normalnie. W związku z tym Komisja uważa, że nie można uznać, że w odniesieniu do niektórych rodzajów działalności, które nie są objęte zakresem art. 107 ust. 3 lit. c) TFUE, nie można uznać za działalność gospodarczą. # Co się stało \ (wszystkie czasy UTC\) Począwszy od 00: 22 w dniu 20 lipca 2026, GitHub zaczął zwracać wysokie błędy dla następujących wniosków API: * "applications / * / token" * 'repos / * / commits' * 'repos / * / * / content / *' * 'repos / * / * / hooks' * 'repos / * / * / haki / * * 'repos / * / * / keys' * 'repos / * / * / pulls' * 'repos / * / * / statuses / * CircleCI opiera się na tych próbach, aby prawidłowo uruchomić i uruchomić rurociągi. O 00: 22 nasz wewnętrzny monitoring powiadomił nas o problemie. Nasz zespół rozpoczął dochodzenie i stwierdził, że niewielka liczba rurociągów należących do projektów GitHub albo nie uruchomiła, albo przebiegła jako rurociągi błędów. Obejmowały one planowane rurociągi i przepływy pracy. Ponadto niewielka liczba przepływów pracy klientów doświadczyła zaciętych miejsc pracy i wymagała ponownego uruchomienia przepływu pracy do naprawy. O godzinie 01: 45 GitHub odzyskał i przetwarzanie rurociągów wróciło do normalnego poziomu operacyjnego. Tylko rurociągi uruchomione w czasie trwania zdarzenia zostały naruszone, a klienci powinni ponownie uruchomić te rurociągi. Przyszłe zapobieganie i usprawnienie procesu Aktywnie pracujemy nad poprawą odporności przetwarzania rurociągów podczas zakłóceń w usługach GitHub w celu zmniejszenia wpływu podobnych incydentów na klientów w przyszłości. Jesteśmy funkcje oceny, które pomogą klientom odzyskać z zredukowanych kroków manualnych po rozwiązaniu incydentów. Doświadczenie Klienta jest naszym najwyższym priorytetem i zobowiązujemy się do ciągłego zwiększania niezawodności naszych systemów, aby dopasować zaufanie naszych klientów do nas. Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 lipca 2026 23:04 UTCinvestigating

   Badamy problem, w którym klienci mogą zobaczyć błędy ładowania aplikacji internetowej CircleCI i logowania się, wraz z rurociągami i planowanych przepływów roboczych, które nie zaczynają się lub się spóźniają. Jest to związane z trwającym incydentem dotyczącym GitHuba. Możesz śledzić status GitHub pod adresem https: / / www.githubstatus.com / invents / gxycch3076xk. Nasi inżynierowie prowadzą śledztwo. Dostarczymy kolejną aktualizację, jak tylko będziemy mieli więcej informacji do przekazania.

2. 16 lipca 2026 23:42 UTCidentified

   Nadal obserwujemy wysokie wskaźniki błędów w API GitHub, które wpływają na proces logowania i przepływu pracy. Będziemy nadal monitorować GitHub API do powrotu do zdrowia.

3. 17 lipca 2026 00:09 UTCmonitoring

   Co się dzieje? Incydent dotyczący GitHub został złagodzony i jest obecnie monitorowany po stronie GitHuba. Możesz śledzić status GitHub pod adresem https: / / www.githubstatus.com /. Czego można się spodziewać? Dostęp do aplikacji internetowej CircleCI, logowanie się oraz przetwarzanie rurociągu i przepływu pracy wracają do normy. W miarę stabilizacji systemów nadal mogą wystąpić okresowe błędy lub opóźnione planowane rurociągi i przepływy pracy. Dziękujemy za cierpliwość, podczas gdy my będziemy monitorować pełną rekonwalescencję.

4. 17 lipca 2026 00:26 UTCresolved

   Incydent wpływający na API GitHuba spowodował, że klienci CircleCI doświadczyli błędów w załadowaniu aplikacji internetowej i zalogowaniu się, wraz z rurociągami i regularnymi przepływami roboczymi, które nie rozpoczęły się lub nie przebiegały z opóźnieniem. GitHub rozwiązał podstawowy incydent (https: / / www.githubstatus.com /) i cała jego funkcjonalność wróciła do normy. Klienci, których prace lub rurociągi zawiodły, mogą je ponownie uruchomić. Planowane rurociągi i przepływy pracy, które zostały pominięte podczas incydentu, nie będą działać automatycznie i będą musiały zostać ponownie uruchomione. Dziękujemy za cierpliwość.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 14 lipca 2026 22:54 UTCidentified

   W dniu 13 lipca między 15: 30 UTC a 22: 40 UTC doświadczyliśmy opóźnień w rozpoczęciu pracy w klasie zasobów Docker (Gen 2) ze względu na ograniczenia przepustowości od naszego dostawcy chmur. Opóźnienia sięgają około 1 minuty 48 sekund. Nadal doświadczamy tych opóźnień od około 15: 45 UTC. Jak dotąd opóźnienia sięgają około 1 minuty 19 sekund. Współpracujemy z naszym dostawcą chmur, aby zwiększyć pojemność i uaktualnić ten incydent w miarę zmian sytuacji.

2. 15 lipca 2026 00:32 UTCresolved

   W dniu 13 lipca między 15: 30 UTC a 22: 40 UTC doświadczyliśmy opóźnień w rozpoczęciu pracy w klasie zasobów Docker (Gen 2) ze względu na ograniczenia przepustowości od naszego dostawcy chmur. Ta sama kwestia powtórzyła się 14 lipca między 15: 45 UTC a 22: 50 UTC. Opóźnienia osiągnęły 25 minut 13 lipca i do 24 minut 14 lipca. Średnie + i 2 klasy X- duze + byly najdluzsze czekania. Wcześniejsze aktualizacje w tym incydencie podane dane oparte na średnim czasie oczekiwania, które nie odzwierciedlały maksymalnego wpływu niektórzy klienci mogli doświadczyć. Czas oczekiwania powrócił do normy. Kontynuujemy współpracę z naszym dostawcą chmur, aby zwiększyć przepustowość przed kolejnym okresem szczytu. Dziękuję za cierpliwość.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 14 lipca 2026 02:49 UTCinvestigating

   Obecnie badamy błędy logowania wpływające na niektórych klientów używając Bitbucket jako dostawcy tożsamości.

2. 14 lipca 2026 03:29 UTCinvestigating

   Nasz zespół nadal bada błędy logowania wpływające na niektórych klientów używając Bitbucket jako dostawcy tożsamości.

3. 14 lipca 2026 03:51 UTCinvestigating

   Co ma wpływ Niektórzy klienci logują się z Bitbucket- powiązane tożsamości są dotknięte. Może to również obejmować klientów logujących się z GitHub, ale mają powiązaną tożsamość Bitbucket na ich koncie. Ponadto niektórzy klienci doświadczają przepływów pracy, które nie rozpoczynają lub aktualizują. Czego można się spodziewać? Dotknięci klienci mogą zobaczyć błędy logowania. Niektórzy klienci mogą również zauważyć przepływy pracy, które nie zaczynają lub nie aktualizują się zgodnie z oczekiwaniami. Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie badają. Następna aktualizacja Dostarczymy kolejną aktualizację jak tylko będziemy mieli więcej informacji do przekazania

4. 14 lipca 2026 04:21 UTCmonitoring

   Co ma wpływ Niektórzy klienci logujący się z Bitbucket- powiązane tożsamości zostały naruszone. Może to również obejmować klientów logujących się z GitHub, którzy mają powiązaną tożsamość Bitbucket na ich koncie. Niektórzy klienci również doświadczyli przepływów pracy, które nie rozpoczęły się ani nie uaktualniły. Czego można się spodziewać? Wystawiono rozwiązanie. Monitorujemy sytuację, aby potwierdzić pełną poprawę. Następna aktualizacja Dostarczymy aktualizację jeśli coś się zmieni

5. 14 lipca 2026 05:15 UTCresolved

   Problem, w którym klienci logujący się przy pomocy tożsamości powiązanej z Bitbucketem doświadczyli błędów logowania, a niektórzy klienci doświadczyli przepływów pracy, które nie rozpoczęły się lub nie zaktualizowały, został rozwiązany. Co może jeszcze doświadczenie i trzeba zrobić - Jeśli używasz Bitbucket jako metody logowania, wyloguj się i ponownie uwierzytelniaj integrację Bitbucket CircleCI na swoim koncie. - Jeśli któraś z twoich operacji jest zablokowana lub wykazuje brak kontroli stanu, proszę uruchomić ponownie, aby podnieść fix. - W przypadku dalszego występowania problemów po podjęciu tych kroków, należy skontaktować się z CircleCI Support. Dziękujemy za cierpliwość, podczas gdy nasz zespół pracował nad wdrożeniem poprawki.

6. 14 lipca 2026 22:31 UTCpostmortem

   Podsumowanie Od 01: 33 UTC do 05: 18 UTC w dniu 14 lipca 2026, klienci o tożsamości powiązanej z Bitbucketem nie byli w stanie zalogować się do CircleCI, a niektórzy klienci doświadczyli przepływów pracy, które nie udało się uruchomić lub uaktualnić, ze względu na zmianę sposobu, w jaki Bitbucket 's usługi OAuth raporty uprawnień do konta. O 05: 07 UTC, wprowadziliśmy poprawkę, która poprawiła jak nasze systemy odczytują zaktualizowane pole uprawnień. Niektórzy klienci musieli się wylogować i ponownie potwierdzić swoją integrację Bitbucket po wdrożeniu poprawki. Nasze systemy kontynuowały przetwarzanie zaległości dotkniętych miejsc pracy do 08: 39 UTC. Dziękujemy naszym klientom za cierpliwość, kiedy rozwiązaliśmy ten incydent. Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości. Strona statusu tego incydentu znajduje się [tutaj] (https: / / status.circleci.com / invents / gsyjwybg477g). # # Tło CircleCI obsługuje logowanie się z kontem GitHub, Bitbucket lub e-mail i hasło. Kiedy klient loguje się z tożsamości powiązanej z Bitbucket- linked, lub gdy CircleCI musi odświeżyć dostęp klienta w ich imieniu, wymieniamy żeton autoryzacji z Bitbucket 's OAuth usługi. Ta wymiana zawiera listę uprawnień, lub "sops", klient przyznał nam, które Bitbucket i CircleCI używać do potwierdzenia, co CircleCI jest upoważniony do zrobienia w imieniu klienta. # Co się stało \ (Wszystkie czasy UTC\) W dniu 8 kwietnia 2026 r. [Bitbucket ogłosił zmianę swojej usługi OAuth] (https: / / developer.atclassian.com / cloud / bitbucket / changelog / # CHANGE- 3139): zmieniłoby nazwę pola używanego do zgłaszania uprawnień przyznanych klientowi. Bitbucket prowadził okres przejściowy, podczas którego dostępne były zarówno stare jak i nowe nazwy pól, a następnie w pełni usunął starą nazwę pola 4 maja 2026 roku. Nasze systemy nie zostały zaktualizowane w celu rozpoznania nowej nazwy pola, więc kiedy Bitbucket całkowicie wycofał stare, prośby, które od niego zależały zaczęły zawodzić. O godzinie 01: 33 14 lipca 2026 roku nasze systemy zaczęły nie przetwarzać informacji o zezwoleniach zwróconych do rachunków powiązanych z Bitbucketem, ponieważ nasze systemy nadal oczekiwały starej struktury zezwoleń. Spowodowało to próby logowania się do wszystkich kont powiązanych z Bitbucket- linked, w tym dla klientów, którzy logują się z GitHub, ale mają tożsamość Bitbucket powiązaną z ich kontem. O 01: 59 zautomatyzowany monitoring ostrzegł nasz zespół inżynieryjny o wzroście błędów w systemach dotkniętych. Zespół natychmiast rozpoczął dochodzenie, potwierdził wpływ klienta o 02: 38, a zaalarmował klientów przez naszą stronę statusu o 02: 51. Do 03: 00 drużyna odizolowała porażki od pola Bitbucket. Począwszy od 03: 17, aktualizacja statusu przepływu pracy dla rurociągów Bitbucket należących do klientów z wygasłym tokerem dostępu zaczęła być odrzucona. Sprawdzenie uprawnień Bitbucket jest szeroko stosowane na całej naszej platformie, a te niepowodzenia wpłynęły również na niektóre z naszych wewnętrznych systemów przetwarzania pracy. Spowodowało to, że podzbiór przepływów pracy utknął bez ostatecznego statusu, i spowodowało kilka wniosków o ciągnięcie pokazać brak lub zablokowane kontroli stanu. O 04: 21 zespół wprowadził początkową poprawkę, która rozwiązała problem, przywracając przepływ logowania i zwracając nasze wewnętrzne uprawnienia do normalnej pracy. Niektórzy poszkodowani klienci musieli się wylogować i zalogować z powrotem, aby podnieść fix. Do 05: 07 zespół wprowadził dwie dodatkowe poprawki, aby nasze systemy zaczęły akceptować nowy format pola uprawnień Bitbucket. Rozwiązaliśmy ten incydent o 05: 18. Niektórzy klienci musieli się wylogować i ponownie potwierdzić swoją integrację Bitbucket przed ich konto w pełni odzyskać. Nasze systemy nadal przetwarzały zaległości dotkniętych miejsc pracy, powracając do normalnego poziomu o około 08: 39. Przyszłe zapobieganie i usprawnienie procesu Podejmujemy następujące kroki, aby zapobiec nawrotom i poprawić czas reakcji: * * Utwardzamy kod autoryzacji przed zmianami API. * * Ten incydent zdarzył się, ponieważ nasz system nie radził sobie z przemianowanym polem w odpowiedzi od trzeciego dostawcy tożsamości. Będziemy natychmiast aktualizować nasz kod autoryzacji tak, że nieoczekiwane lub brakujące pola z GitHub, Bitbucket i GitLab są obsługiwane bezpiecznie. * * Ulepszamy jak śledzimy zmiany dostawcy. * * Obecnie monitorujemy już zmiennokształtnych od naszych dostawców tożsamości za dokładnie tego rodzaju przełomowe zmiany, ale nie dodaliśmy tej konkretnej zmiany dostawcy do naszego monitorowania na czas, aby złapać go przed wysyłką. Kontrolujemy i poszerzamy ten monitoring, więc ogłoszenia dostawcy dotrzeć do naszego zespołu, zanim dotkną klientów. * * Poprawiamy klasyfikację i komunikację zdarzeń w najwcześniejszych minutach. * * Wstępna klasyfikacja tego incydentu nie odzwierciedlała od razu jej dotkliwości. Udoskonalamy nasze oprzyrządowanie i wskazówki, aby pomóc inżynierom zidentyfikować i komunikować wpływ klienta szybciej. * * Zwiększamy odporność naszego rurociągu przetwórczego. * Niepowodzenie w tym incydencie spowodowało, że niektóre aktualizacje statusu przepływu pracy zostały raczej zniesione niż ponownie wypróbowane lub wyraźnie ujawnione. Przeglądamy powtórne i błędne zachowanie tego systemu, więc podobne awarie niższego szczebla są bardziej widoczne i łatwiejsze do odzyskania. Doświadczenie Klienta jest naszym najwyższym priorytetem i zobowiązujemy się do ciągłego zwiększania niezawodności naszych systemów, aby dopasować zaufanie naszych klientów do nas. Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 13 lipca 2026 21:52 UTCinvestigating

   Otrzymaliśmy kilka raportów o przerywanych problemach sieciowych między naszą infrastrukturą Mac a dostawcą VCS. Prowadzimy śledztwo i dostarczymy aktualizacje.

2. 13 lipca 2026 22:21 UTCinvestigating

   Nadal badamy te nieregularne problemy z siecią. Wkrótce się dowiemy, doceniamy twoją cierpliwość.

3. 13 lipca 2026 23:13 UTCinvestigating

   Udało nam się odtworzyć ten problem, ale nadal wydaje się być bardzo przerywany. Kontynuujemy współpracę z naszym dostawcą infrastruktury Mac, aby pomóc zdiagnozować problem. Niedługo się dowiemy.

4. 13 lipca 2026 23:35 UTCmonitoring

   Zidentyfikowaliśmy problem. Niektórzy klienci mogą doświadczać miejsc pracy, które zawisają lub nie postęp podczas Github pobrać kroki ze względu na przerywane problemy sieciowe. Nasi inżynierowie aktywnie monitorują. W międzyczasie, widzieliśmy sukces z zwiększeniem no _ output _ timeout do 15 - 20 min, aby dać więcej czasu dla Github fetches. Można tego dokonać stosując się do tego przewodnika: https: / / support.circleci.com / hc / en- us / articles / 360007188574- Build- has- Hit- Timeout- Limit

5. 14 lipca 2026 13:59 UTCidentified

   Niestety są jeszcze niektórzy klienci, którzy mogą doświadczać miejsc pracy, które wisi lub nie postęp podczas Github pobrać kroki ze względu na trwające problemy przerywane sieci z naszym dostawcą infrastruktury Mac. Nasi inżynierowie aktywnie z nimi pracują, by to rozwiązać. Doceniamy twoją cierpliwość. W międzyczasie, widzieliśmy sukces z zwiększeniem no _ output _ timeout do 15 - 20 min, aby dać więcej czasu dla Github fetches. Można tego dokonać stosując się do tego przewodnika: https: / / support.circleci.com / hc / en- us / articles / 360007188574- Build- has- Hit- Timeout- Limit

6. 14 lipca 2026 15:35 UTCidentified

   Nasz dostawca infrastruktury Mac testuje zmiany w konfiguracji sieci w celu odizolowania źródła problemu. Aktywnie potwierdzamy, czy to rozwiązuje skutki i wkrótce przejdziemy do kolejnej aktualizacji. W międzyczasie, zwiększenie no _ output _ timeout do 15- 20 min nadal pomaga: https: / / support.circleci.com / hc / en- us / articles / 360007188574- Build- has- Hit- Timeout - Limit

7. 14 lipca 2026 16:31 UTCidentified

   Zidentyfikowaliśmy problem jako niektóre trasy przychodzące od poszkodowanego dostawcy VCS powodujące znacznie niższe dostępne przepustowość, co negatywnie wpływa na czasy pobierania repo. Współpracujemy z naszym dostawcą infrastruktury Mac, aby spróbować przenieść ruch przychodzący na inną trasę, jednak proces ten może zająć dłuższy czas, aby zakończyć. Będziemy nadal dostarczać aktualizacje w miarę ich dostępności. Jak dzieliliśmy się w poprzednich aktualizacjach, zwiększenie no _ output _ timeout do 15- 20 min nadal pomaga: https: / / support.circleci.com / hc / en- us / articles / 360007188574- Build- has- Hit- Timeout - Limit

8. 14 lipca 2026 16:58 UTCmonitoring

   Nasz dostawca infrastruktury Mac przesunął trasy przychodzące i widzimy ożywienie w VCS pobrać czasy. Będziemy nadal monitorować tę kwestię w ciągu najbliższych kilku godzin. Niedługo się dowiemy.

9. 14 lipca 2026 18:28 UTCmonitoring

   Wciąż obserwujemy powolne, progresywne odzyskiwanie w VCS. Wkrótce będziemy kontynuować monitorowanie i aktualizację. Doceniamy twoją cierpliwość.

10. 14 lipca 2026 20:18 UTCinvestigating

    Zaczynamy widzieć, jak VCS znowu przyciąga czas. Nasz zespół inżynieryjny aktywnie bada i współpracuje z naszym dostawcą infrastruktury Mac, aby rozwiązać ten problem. Doceniamy twoją cierpliwość.

11. 14 lipca 2026 22:15 UTCmonitoring

    Nasz dostawca infrastruktury Mac przesunął większy ruch na dostawców sieci roboczych i zaczynamy dostrzegać znaczące ożywienie ponownie w VCS pobrać czasy. Jak zawsze, nasz zespół inżynieryjny będzie to uważnie monitorować i wkrótce dostarczymy kolejną aktualizację.

12. 14 lipca 2026 23:18 UTCresolved

    W ciągu ostatnich kilku godzin zauważamy, że VCS odzyskuje czas. Rozwiążemy ten incydent, a nasz zespół inżynieryjny będzie nadal uważnie monitorował. Bardzo doceniamy Państwa cierpliwość, pracując nad tym z naszym dostawcą infrastruktury Mac. Proszę skontaktować się z naszym zespołem wsparcia, jeśli masz jakieś problemy.

13. 16 lipca 2026 01:56 UTCpostmortem

    Podsumowanie Od 18: 00 UTC w dniu 13 lipca 2026 do 23: 18 UTC w dniu 14 lipca 2026, niektórzy klienci prowadzący prace na MacOS floty CircleCI doświadczyli pracy, które wisiały lub nie postępowały podczas GitHub pobrać kroki. Dla tych klientów, GitHub pobrać kroki, które zwykle trwa 1-2 minut zajęło 20- 30 minut, a czas minął. Problem ten został spowodowany problemem przepustowości i routingu na ścieżce sieciowej pomiędzy naszym dostawcą infrastruktury Mac i GitHub, a związane z tym problemy przerywane sieci spowolniły połączenia z GitHub. Podczas całego incydentu nasz zespół pracował bezpośrednio z naszym dostawcą infrastruktury Mac, aby zidentyfikować i przekierować ruch z dala od dotkniętych ścieżek sieciowych. Rozwiązaliśmy pierwsze zdarzenie o 19: 40 UTC 13 lipca. Kwestia ta powtórzyła się o 21: 52 UTC tego samego dnia, ponownie otwarliśmy ten incydent, i została w pełni rozwiązana do 23: 18 UTC 14 lipca. Nasza flota miała podobny problem kilka tygodni temu. Od dnia 20: 18 UTC w dniu 24 czerwca 2026 r. do dnia 03: 09 UTC w dniu 25 czerwca 2026 r. klienci doświadczyli [podobnego incydentu] (https: / / status.circleci.com / invents / gvysjmkf4ct9) wpływającego na zdolność miejsc pracy w MacOS do dotarcia do GitHub. Ten incydent był również spowodowany problemem routingu sieci w naszym dostawcą infrastruktury Mac. Dziękujemy naszym klientom za cierpliwość, podczas gdy pracowaliśmy nad tym incydentem. Zobacz poniżej szczegółowe działania, które CircleCI i nasz dostawca infrastruktury Mac będą podejmować. Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości. Strony stanu tego incydentu można znaleźć [tutaj] (https: / / status.circleci.com / invents / n1tc2lw9q7l0) i [tutaj] (https: / / status.circleci.com / invents / 7cnl777wp9qz). # # Tło Roboty w zakresie MacOS CircleCI są prowadzone przez trzeciego dostawcę infrastruktury Mac. Usługodawca ten łączy się z szerszym internetem, w tym z usługami takimi jak GitHub, poprzez wiele zbędnych ścieżek sieci wyższego szczebla. W przypadku gdy jedna z tych ścieżek doświadcza zmniejszonej przepustowości lub problemów z routowaniem, zadania, które pobierają kod lub zależności od miejsca docelowego wzdłuż tej ścieżki sieciowej, mogą spowolnić lub zawiesić się w sposób przerywany, nawet gdy platforma CircleCI, dostawca infrastruktury trzeciej strony i usługa docelowa działają normalnie. # Co się stało _\ (Wszystkie czasy UTC\) _ 13 lipca o godzinie 18: 00 niektórzy klienci pracujący w MacOS zaczęli doświadczać niepowodzeń i opóźnień w pobieraniu kodu i zależności od GitHub. Otworzyliśmy dochodzenie i powiadomiliśmy naszych klientów o 18: 55. Do 19: 04 nasz dostawca infrastruktury Mac zidentyfikował zwiększoną latencję na jednej ze ścieżek sieciowych i przekierował ruch wokół niej. Odzyskaliśmy czas, przenieśliśmy incydent do 'Monitoring' o 19: 29, a do 'Resoluted' o 19: 40. O godzinie 20: 44 UTC klienci zgłosili, że problem powrócił. Ponownie otworzyliśmy incydent i zaktualizowaliśmy naszą stronę o 21: 52. W ciągu następnych dwóch godzin ściśle współpracowaliśmy z naszym dostawcą infrastruktury w celu gromadzenia danych diagnostycznych w celu odizolowania dotkniętej trasy sieci. W międzyczasie opublikowaliśmy wytyczne zalecające, aby klienci zwiększyli swoje ustawienia "no _ output _ timeout" do 15- 20 minut, aby dać GitHub więcej czasu na ukończenie odbioru w czasie przerw i przenieśli stronę statusu do "Monitoring" o 23: 35. Po opublikowaniu wytycznych o 23: 35 UTC 13 lipca spodziewaliśmy się, że problem sieci bazowej ulegnie poprawie z dnia na dzień. Nie. 14 lipca o godz. 13: 59 UTC potwierdziliśmy, że klienci nadal doświadczają niepowodzeń przerywanych i przesunęliśmy stronę statusu z powrotem na "Śledztwo". Nasz zespół inżynieryjny odtworzył awarię bezpośrednio za pomocą własnych narzędzi testowych, które pomogły potwierdzić, że jest to ogólna kwestia "git- fetch", a nie coś specyficznego dla konkretnego narzędzia do budowy, obrazu kontenera lub aktualizacji oprogramowania. O 15: 35 zaktualizowaliśmy stronę statusu, aby podzielić się tym, że nasz dostawca infrastruktury testował zmiany w konfiguracji sieci, aby wyodrębnić źródło problemu. O 16: 31 ponownie zaktualizowaliśmy stronę statusu, aby podzielić się tym, że zidentyfikowaliśmy przyczynę jako zmniejszenie przepustowości przychodzącej na określonej trasie i że współpracowaliśmy z naszym dostawcą, aby przenieść ruch na inną trasę. O 16: 36, nasz dostawca infrastruktury zidentyfikował dotknięte trasy sieci i przeniósł ruch z dala od nich, pobrać czasy odzyskane, a o 16: 58 zaktualizowaliśmy stronę statusu do "Monitoring". Wczesnym popołudniem niektórzy klienci znów oglądali wolne pobieranie czasu, a my przenieśliśmy stronę statusu z powrotem do 'Śledztwo' o 20: 18. Nasz dostawca infrastruktury zidentyfikował dwie dodatkowe ścieżki sieciowe z pogorszeniem wydajności i przeniósł ruch z dala od nich o 22: 07. Czasy pobierania ustabilizowały się w ciągu następnej godziny, a my zaznaczyliśmy zdarzenie "rozwiązane" o 23: 18. W sumie, klienci pracujący na Mac może doświadczyć przerywane spowolnienia pracy lub awarii części okna między 18: 00 UTC w dniu 13 lipca i 23: 18 UTC w dniu 14 lipca. Od tego czasu nasz dostawca infrastruktury zgłosił wyniki czystych testów w całej swojej sieci i uważa, że problem podstawowej przepustowości powstał dalej w górę rzeki, bliżej GitHub, a nie w obrębie własnej sieci. Nadal uważnie to monitorujemy. Przyszłe zapobieganie i usprawnienie procesu Podejmujemy następujące kroki, aby zapobiec nawrotom i poprawić czas reakcji: * * Budujemy dodatkowy zautomatyzowany monitoring dla floty MacOS GitHub- fetch wydajności. * * Nasz zautomatyzowany monitoring nie wykrył tego incydentu. Obecnie dodajemy monitorowanie końcowe w odniesieniu do sieci GitHub w szczególności w celu aktywnego wykrywania podobnych problemów. * * Współpracujemy bezpośrednio z naszym dostawcą infrastruktury Mac na szybsze, bardziej aktywne wykrywanie. * * Prosimy naszego dostawcę, aby zbudował monitoring, który może wykryć zdegradowaną ścieżkę sieciową i przekierować ją automatycznie, zamiast polegać na CircleCI, aby zidentyfikować i poprosić o przekierowanie podczas aktywnego incydentu. * * Zamieniamy narzędzia diagnostyczne, które zbudowaliśmy podczas tego incydentu w zdolność stojącą. * * Pozwoli nam to wykryć i odtworzyć tę klasę awarii sieci na żądanie, zamiast montować infrastrukturę testową podczas aktywnego incydentu. * * Przeglądamy nasz proces reagowania na incydenty w celu uzyskania odpowiedniego okna potwierdzenia przed oznaczeniem incydentu związanego z siecią. * * Ten incydent krótko powtórzył się po wczesnej, przedwczesnej rozdzielczości; formalizujemy minimalny okres potwierdzonego-czystego monitorowania przed zamknięciem incydentów tego typu. Będziemy nadal dostarczać regularne aktualizacje w trakcie dochodzenia i rekultywacji. * * Aktywnie przenosimy się z jednego dostawcy infrastruktury Mac * * * * do wielu dostawców. * * Umożliwi to CircleCI przekierowanie przychodzących zadań do najbardziej dostępnego i wydajnego dostawcy. Doświadczenie Klienta jest naszym najwyższym priorytetem i zobowiązujemy się do ciągłego zwiększania niezawodności naszych systemów, aby dopasować zaufanie naszych klientów do nas. Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 13 lipca 2026 18:55 UTCinvestigating

   Otrzymaliśmy raporty o przerywanych problemach sieciowych między naszą infrastrukturą Mac i dostawcą VCS. Prowadzimy śledztwo i dostarczymy aktualizacje.

2. 13 lipca 2026 19:11 UTCidentified

   Współpracujemy z naszym dostawcą infrastruktury Mac 'a, aby spróbować złagodzenia. Wkrótce się dowiemy.

3. 13 lipca 2026 19:29 UTCmonitoring

   Nasz dostawca infrastruktury Mac wdrożył naprawę, zaczynamy dostrzegać ożywienie. Monitorujemy i wkrótce będziemy aktualizować.

4. 13 lipca 2026 19:40 UTCresolved

   Potwierdziliśmy rozwiązanie z naszym dostawcą infrastruktury i udany test z naszej strony. Jeśli klienci nadal widzą nieudany bieg, proszę uruchomić ponownie dla udanego połączenia i dotrzeć do Wsparcie, jeśli jakiekolwiek dalsze problemy.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.