Historia awarii Shiphawk

1. 2 września 2026 16:24 UTCmonitoring

   Usługi internetowe FedEx doświadczają obecnie zdegradowanej wydajności, a niektórzy klienci zgłosili problemy rezerwacji przesyłek FedEx. Będziemy nadal monitorować sytuację, podczas gdy FedEx będzie pracował nad rozwiązaniem problemu. Obecne czasy odpowiedzi FedEx są dostępne tutaj: https: / / www.shippingapimonitor.com / history.html? api = fedex

2. 2 września 2026 21:59 UTCresolved

   Rozwiązano to po stronie FedEx.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 25 sierpnia 2026 14:10 UTCinvestigating

   Niektórzy klienci doświadczają spowolnienia dostępu do WMS. Nasz zespół aktywnie bada sprawę.

2. 25 sierpnia 2026 16:01 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 25 sierpnia 2026 17:40 UTCresolved

   Ten incydent został rozwiązany. Podzielimy się szczegółami, jak tylko będą dostępne.

4. 27 sierpnia 2026 22:21 UTCpostmortem

   # # Post- Incydent Report: WMS Slowness and Errors for Workhouses on One Database Instance - August 25, 2026 / Stan: Rozwiązane * * Okno incydentu: * * 25 sierpnia 2026, ~ 04: 30 - 08: 45 PDT\ (07: 30 - 11: 45 ET\) * * Affected: * * Klienci, których bazy danych są hostowane na jednej instancji WMS w naszej grupie magazynowej US- East: czas obciążenia strony do 20x normalne, i okresowe błędy na skanerze i ekranach admin w najgorszym okresie. * * Nie dotyczy: * * Wszystkie inne instancje bazy danych WMS i grupy magazynowe, platforma TMS, integralność danych\ (żadna transakcja nie została utracona, powielona, lub częściowo zastosowana\) oraz wszystkie zakończone prace - każda transakcja, która została zaakceptowana, była prawidłowo przetwarzana. - Czy coś cię dotknęło? Wpływ był ograniczony do klientów, których bazy danych WMS są hostowane na jednej konkretnej instancji bazy danych w naszej grupie magazynów US- East i tylko w godzinach porannych 25 sierpnia (około 04: 30 - 08: 45 PDT / 07: 30 - 11: 45 ET\). Jeśli podczas tego okna nie zauważyłeś wolnych obciążeń stron w WMS, środowisko nie było zaangażowane. Wszystkie inne instancje bazy danych WMS i grupy magazynowe, a także cała platforma TMS, działa normalnie w całym. Podsumowanie Wieczorem 24 sierpnia, trzeci serwis ETL, który kopiuje dane ShipHawk do naszego magazynu danych ponownie uruchomił dużą partię swoich zadań synchronizacji w jednym z naszych baz danych produkcji. Każde ponownie rozpoczęte zadanie rozpoczęło ponownie odczytywanie zaległości historycznych danych zmian z pełną prędkością, równolegle i bez jakiegokolwiek ograniczenia stawki. Pojemność odczytu wzrosła do około pięciu razy więcej niż oczekiwano i zużyła większość przepustowości dysku dostępnej dla tej instancji bazy danych. Zaczęło się to z dnia na dzień, gdy działalność magazynowa jest lekka, więc nie miało to żadnego wpływu na działalność w tym czasie. Kiedy 25 sierpnia rozpoczęły się poranne zmiany US- East, na kanale nasyconym już dodano normalną aktywność WMS, a instancja osiągnęła limit przepustowości. Z punktu widzenia aplikacji pojawiło się to jako powolne odpowiedzi bazy danych: pytania, które zwykle powracają w milisekundach, trwały znacznie dłużej, praca w kolejce za nimi, a strony ładowane powoli. Jeżeli odpowiedź w bazie danych przekroczyła limit czasu aplikacji, strona zwróciła błąd zamiast wczytywania. Usługa pozostała operacyjna przez cały czas. W całym dotkniętym przypadku, klienci przetwarzali około 70% wolumenu normalnie obsługiwanego w tym oknie\ (typy, opakowania i inwentaryzacja przesuwa\), chociaż doświadczenie było powolne i czasami trudne do pracy z, a stopień wpływu różnił się między klientami. Sytuacja rozwiązana poprzez cofnięcie uwierzytelniania bazy danych usług ETL w całości o godzinie 08: 37 PDT. Baza danych odzyskała się w ciągu ośmiu minut. Opóźnione prace przepłukały się w ciągu następnych dwóch godzin, a wszystkie wpływające magazyny wróciły do normalnego tempa. Nie było lub nie jest wymagane działanie klienta, a dane nie zostały naruszone. Żadna transakcja nie została utracona, powielona lub częściowo zastosowana - sprawdziliśmy to w dziennikach integracyjnych obejmujących całe okno incydentu. Prace, które zostały złożone albo poprawnie ukończone, albo nie pomyślnie przed dokonaniem jakichkolwiek zmian. Poniżej omówiono to bardziej szczegółowo. * * What was affected * Wpływ był ograniczony do klientów, których bazy danych są hostowane na dotkniętych WMS instancji bazy danych w grupie magazynowej US- East. W całym oknie incydentu system był powolny w całej planszy - skaner i strony admin, które zwykle ładować w znacznie poniżej sekundy trwało wiele razy dłużej - a gdzie odpowiedź bazy danych przekroczyła czas aplikacji, strona zwróciła błąd zamiast wczytywania. Jak to wyglądało w praktyce: * * Podłoga magazynu: * * strony skanera\ (zbieranie, przenoszenie, dostosowywanie zapasów\) załadowane bardzo powoli; pracownik, który próbował ponownie, gdy strona została zablokowana może otrzymać stronę błędu i musi wrócić i powtórzyć akcję. * * Błędy koncentrowały się raczej na jednym wybuchu niż rozprzestrzenianiu się całego incydentu. * * Większość z nich znalazła się w jednym 15-minutowym oknie na szczycie zatoru\ (06: 15 - 06: 30 PDT\). Liczenie potwierdzonych stron błędów w logach web- server i aplikacji, najbardziej dotknięty magazyn widział 71 w tym oknie. * * System pozostał cały. * * Każda zgłoszona transakcja została zakończona poprawnie lub nie została zakończona w sposób czysty przed dokonaniem jakiejkolwiek zmiany. Podczas najgłębszego okna spowolnienia możemy pokazać setki transakcji zakończonych sukcesem dla użytkowników, którzy kontynuowali pracę. * * What was NOT affected * / Integralność danych. Błędy wystąpiły na samym początku przetwarzania wniosku, zanim nastąpiła jakakolwiek zmiana. Żadna transakcja nie została utracona, powielona lub częściowo zastosowana. Każde wypełnienie, przeniesienie inwentarza i wysłanie przesyłki dokonało się poprawnie - zweryfikowaliśmy dzienniki integracji dla okna zdarzenia. * * Synchronizacja zamówień i przesyłek do ERP i rynków * * poprawnie ukończone w całym; posty, które w kolejce w kolejce podczas spowolnienia zostały dostarczone w całości podczas przechwytywania\ (sprawdzone w dziennikach integracyjnych - brak nieudanego wysłania\). * * Wszystkie inne środowiska. * * Magazyny na innych instancjach baz danych, a cała platforma TMS, działa normalnie. * * Bezpieczeństwo i praca. * * W żadnym momencie nie było żadnych granic bezpieczeństwa. Usługa trzeciej strony, o której mowa, jest sprzedawcą danych, działającym w oparciu o wydane przez nas referencje; problemem była wielkość odczytu, a nie nieautoryzowany dostęp. # # # Timeline\ (all times PDT; add 3 hours for ET\) 124; czas 124; zdarzenie 124; {C: $999966} {f: Serwer ETL restartuje ~ 22 zadania synchronizacji z bazą danych w trzyminutowym oknie. Każdy zaczyna ponownie odczytywanie danych historycznych zmian z pełną prędkością. 124; 24 sierpnia, 22: 54 - 23: 50 X124; Czytaj głośność wspina się około pięć razy więcej niż oczekiwany szczyt, pochłaniając większość przepustowości dysku dostępnego dla instancji. Nocny ruch magazynowy jest lekki, więc nie ma jeszcze widocznego efektu klienta. 124; Sie 25, ~ 04: 30 Sie 124; US- Wschodni magazyn poranne zmiany zaczynają. Połączone zapotrzebowanie przekracza ograniczoną prędkość sieciową; kolejki rozpoczynają budowę, a pierwsze strony stają się wolniejsze niż zwykle. 124; 05: 30 124; Automatyczne alarmy monitorowania czasu reakcji jako ramps działalności magazynowej w górę; zgłoszenia klientów powolności przyjechać w tym samym okresie. Śledztwo zaczyna się. 124; 06: 00 - 07: 00 124; Maksymalne przeciążenie: połączenia w bazie danych wzrosną do ~ 15x normalnie, jak żądania stos; fala błędów scanner- scanner występuje\ (06: 15- 06: 30\). VIId; THE 124; 06: 50 THE 124; Zidentyfikowana przyczyna korzeniowa: szerokość pasma dysku powyżej limitu instancji; strumienie replikacji sprzedawcy zidentyfikowane jako sterownik. 124; 07: 00 124; Najpoważniejsze zapytania w raporcie wewnętrznym wyłączone z bezpłatnej przepustowości - częściowe zwolnienie. 124; 07: 20 - 08: 30 124; zadania synchronizacji usług ETL są przerywane w falach w konsoli, a sesje bazy danych zakończone; usługa automatycznie ponownie łączy się w ciągu kilku sekund za każdym razem i kontynuuje czytanie. W tym okresie rozpoczyna dodatkowe prace. 124; 124; 08: 35 124; Dane z bazy danych usług ETL są zablokowane, a sesje zakończyły się w ostatnim czasie. Database queues drenage; page response times return to normal. Kończy się wpływ na klienta. Dlaczego rozdzielczość zajęła ~ 3 godziny od pierwszych raportów Trzy czynniki przedłużyły linię czasową. Po pierwsze, spust nastąpił 7 godzin przed objawami. Usługa ETL ponownie odczyt przebiegł w ciągu nocy i już zużył dostępną przepustowość, ale z oświetleniem aktywności magazynowej w tej godzinie ograniczenie spowodowało jedynie niewielką zmianę w czasie reakcji systemu - poniżej naszych progów alarmowych - więc poszło niewykryte. Nasz zautomatyzowany monitoring zaalarmował, gdy aktywność magazynu wzrosła rano, ale do tego czasu zmiana miała siedem godzin i nie było niedawne wprowadzenie lub zmiana konfiguracji, aby wskazać. Po drugie, odczyty replikacji usługi ETL są niewidoczne dla standardowych dzienników zapytań w bazie danych - używają raczej protokołu replikacji niż zapytań - tak więc identyfikują je jako wymagane przez konsumenta dowody korelacji dysku, sieci i poziomu połączeń. Po trzecie, usługa ETL jest zbudowana, aby przetrwać przerwy: wstrzymanie pracy i zakończenie jej połączeń nie powiodło się jako ograniczenie, ponieważ ponownie łączy się automatycznie w ciągu kilku sekund, i ponownie rozpoczęło dodatkowe zadania podczas gdy my wstrzymywaliśmy innych. Tylko cofnięcie jego mandatu go zatrzymało. # What we are changing * * Dostrajanie progów alarmowych WMS w czasie reakcji. * * Stan za tym incydentem był obecny przez siedem godzin w ciągu nocy, ale pod lekkim obciążeniem poruszał czas reakcji zbyt mało, aby przekroczyć nasze progi alarmowe - więc pierwszy alarm przyszedł tylko raz aktywność magazynowa wzrosła i klienci byli już dotknięci. Dostrajamy te progi, aby były wrażliwe na mniejsze zmiany w czasie reakcji WMS, w tym przy niskim obciążeniu, więc wydarzenia takie jak ten są łapywane i działają zanim dotrą do klientów. Obejmuje to ostrzeganie o konkretnych głównych wskaźnikach tego incydentu - zużyciu przepustowości dysku i głębokości kolejki dysku. * * Baza danych została przeniesiona do typu instance ze znacznie większą przepustowością dysku * *, co daje znaczący zagłówek powyżej szczytowego zapotrzebowania na wchłonięcie kolców tego rodzaju. * * Kontynuujemy śledztwo ze sprzedawcą ETL. * * Mamy otwartą sprawę z nimi, poszukując wyjaśnienia dla równoczesnego ponownego uruchomienia pracy, i wymagających ograniczenia stóp i pułapów zbieżnych do ponownego odczytu ze źródłami klientów. Prace trwają.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 sierpnia 2026 14:06 UTCinvestigating

   Otrzymaliśmy raporty, że TMS WebPortal zwraca błędy lub nie ładuje dla niektórych klientów. Prowadzimy aktywne śledztwo w tej sprawie i dostarczymy aktualizacje w miarę dostępności większej ilości informacji.

2. 20 sierpnia 2026 15:02 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 20 sierpnia 2026 15:16 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

4. 20 sierpnia 2026 18:06 UTCresolved

   Ten incydent został rozwiązany.

5. 20 sierpnia 2026 19:35 UTCpostmortem

   # Post- Incydent Report: Podwyższone API i błędy logowania - 20 sierpnia 2026 / Stan: Rozwiązane * * Okno incydentu: * * 20 sierpnia 2026, 06: 31 - 08: 11 PDT\ (13: 31 - 15: 11 UTC\) * * Affected: * * ShipHawk API i żądania deski rozdzielczej w wspólnych środowiskach produkcyjnych, plus usługa logowania. Wpływ był raczej częściowy, a nie całkowity: około 25% ogólnego ruchu API na [shiphawk.com] (http: / / shiphawk.com) nie powiodło się w trakcie jego dotkniętego okna; wskaźniki awarii w dotkniętych środowiskach wahały się od około 37% do 48%, a około 41% wniosków o usługi loginowe nie powiodło się. * * Nie dotyczy: * * Przetwarzanie w tle\ (wszystkie zaplanowane zadania, odpisy, haki webhaki, generowanie etykiet async, śledzenie i komunikacja nośna działały normalnie\), integralność danych. Podsumowanie Rano 20 sierpnia, operacja systemu krytycznego aktualizacji bezpieczeństwa opublikowanej przez Ubuntu - i zastosowanej automatycznie przez nasz standardowy proces łatania - zawierała wadę w komponencie serwera WWW\ (nginx\), która znajduje się przed aplikacją ShipHawk. Pakiet, którego dotyczy wniosek, został opublikowany w dniu 19 sierpnia jako [USN - 8563-3] (https: / / ubuntu tu.com / security / notices / USN - 8563-3). Ubuntu potwierdził, że ta aktualizacja wprowadziła regresję i opublikowała [USN-8563-4] (https: / / ubuntu tu.com / security / notices / USN-8563-4) tego samego dnia, cofając problematyczne zmiany w oczekiwaniu na dalsze dochodzenie. Podczas pracy wadliwej wersji warstwa proxy uszkodziła adres URL wielu przychodzących żądań przed przekazaniem ich do aplikacji. Aplikacja nie mogła dopasować uszkodzonych adresów URL do żadnego znanego punktu końcowego i odpowiedziała * * 404 Nie znaleziono * *. Niepowodzenia były natychmiastowe, czyste odrzucenie: żaden wniosek nie został częściowo przetworzony, przekierowany na złe konto lub utracony po przyjęciu. Nasze serwery nie wszystkie pobierają i instalują aktualizacje bezpieczeństwa systemu operacyjnego w tym samym momencie; kontrole aktualizacji i okna instalacji są rozłożone na hosty. W rezultacie niektóre serwery pobrały wadliwą budowę nginx zanim Ubuntu opublikował poprawiony pakiet, podczas gdy inne sprawdziły później i pobrały poprawioną budowę bezpośrednio. Tylko serwery, które już pobrały wadliwy pakiet, zostały naruszone, gdy ich planowana instalacja działała. Dlatego problem ten pojawił się w sposób przerywany: inne-identyczne żądania mogą się nie udać lub odnieść sukces w zależności od tego, który serwer obsługiwał je. Nawet na serwerach uruchamiających wadliwy pakiet nginx tylko podzbiór żądań nie powiódł się. Regresja miała wpływ na konkretne zasady routingu nginx, a nie na całą konfigurację proxy, więc wiele wzorców URL nadal działało normalnie na danym serwerze. Incydent został całkowicie rozwiązany do 08: 11 PDT po każdym dotkniętym serwerem został uaktualniony do skorygowanego pakietu i zweryfikowany zdrowy. Nie było lub nie jest wymagane działanie klienta. # What was affected Liczby poniżej liczą tylko awarie spowodowane tym incydentem. Zwykłe 404 odpowiedzi\ (przeglądy rekordów, które rzeczywiście nie istnieją, nieprawidłowe adresy URL, bot traffic\) zostały zidentyfikowane poprzez ich odrębny podpis odpowiedzi i wyłączone. 124; Środowisko 124; Zakres 124; Wciśnięte okno\ (PDT\) 124; Nieudane żądania 124; {C: $999966} {f: 124; sh- p-1 environment 124; 2 z 3 serwerów WWW 124; 06: 34 - 08: 08 convidence 124; ş37% żądań na serwerach, których dotyczy; ▼ 25% całkowitego ruchu API 124; 124; Usługa logowania 124; Oba serwery 124; 06: 33 - 08: 08 124; sh-p-2 środowisko 124; 2 z 3 serwerów WWW 124; 06: 31 - 08: 08 continuous 124; 124; sh-p-3 środowisko 124; 2 z 3 serwerów webowych 124; 06: 31 - 08: 11 124; Uzasadnienie Jak to wyglądało w praktyce: * * * Integracje API * * otrzymało odpowiedzi HTTP 404 dla ważnych wniosków. Ponieważ porażki były natychmiastowe i bezpaństwowe, ponowni klienci mogli odnieść sukces, gdy wylądowali na niedotkniętym serwerze. * * * Deska rozdzielcza i logowanie * * stron nie udało się wczytać lub podpisać z przerwami. * Nieprawidłowości zależą od dokładnego adresu URL: niektóre typy zapytań przechodziły bez zmian nawet na wadliwych serwerach, dodając do przerywanego wyglądu. * * What was NOT affected * * * * Praca w tle w ogóle nie miała wpływu. * * Wszystkie asynchroniczne przetwarzanie - zaplanowane zadania, kopie zapasowe, synchronizacja inwentaryzacji, dostawy haków internetowych, generowanie dokumentów i etykiet, komunikacja nośnika i ERP - działa za warstwą proxy i nadal normalnie przez cały incydent. Żadna praca w kolejce nie została utracona ani opóźniona. / Integralność danych. Żadne dane nie zostały utracone, zmienione lub uszkodzone. Wnioski albo wypełniane normalnie, albo odrzucane bezpośrednio. * * * Security and tennancy. * * Żaden wniosek nie został przesłany na inne konto i nie przekroczono granic bezpieczeństwa. Korupcja nastąpiła po zastosowaniu wszystkich kontroli dostępu. Podstawową aktualizacją Ubuntu była prewencyjna łata bezpieczeństwa; podatność na nią nie była wykorzystywana w naszych systemach. # # Timeline\ (all times PDT, August 20, 2026\) * * * 19 sierpnia\ (day\) * * - Ubuntu publikuje aktualizację bezpieczeństwa dla nginx; zgłoszono defekt, a Ubuntu publikuje poprawiony pakiet tego samego dnia. Skorygowana wersja rozprzestrzenia się do publicznych aktualizacji luster w ciągu nocy. * * * Sierpień 19, 18: 24 - 23: 09 * * - Nocna aktualizacja sprawdza serwery, które mają wpływ na późniejszy proces pobierania dziennej aktualizacji nginx. W tych momentach wadliwa budowa jest nadal najnowszą dostępną na lustrach. Ten krok pobiera tylko pakiet; instalacja odbywa się podczas następnego ranka w oknie patch. * * * Sierpień 20, 04: 12 - 05: 05 * * * Inna grupa serwerów przeprowadza nocną aktualizację po tym, jak poprawiona budowa dotrze do luster. Serwery te pobierają stałą wersję i pozostają zdrowe przez cały incydent. * * * ~ 06: 00 * * - Rutynowa, niepowiązana aktualizacja konfiguracji aplikacji jest stosowana dla nadchodzących wydań. To nie ma wpływu na aktualnie wydany funkcjonalność i * * nie odgrywa żadnej roli w incydencie * *, ale ponieważ jest to jedyna znana zmiana tego ranka, staje się pierwszym podejrzanym, gdy pojawią się błędy. * * * 06: 00 * * - Nightly automatic pitching window starts rolling nginx updates across environments. Niektóre serwery już pobrały poprawiony pakiet, podczas gdy inne mają wadliwy pakiet. * * * 06: 31 - 06: 34 - INCIDENT START. * * W miarę postępu w automatycznym oknie łaty, wcześniej pobrany wadliwy pakiet nginx jest zainstalowany na wielu serwerach internetowych i logowania we współdzielonych środowiskach produkcyjnych. Ponieważ harmonogramy łat są rozłożone, nie wszystkie serwery aktualizują na raz, a niektóre serwery pozostają zdrowe. Pierwsze nieudane prośby klientów zaczynają się od * * 06: 31 * *. * * * 06: 35 * * - Automatyczne zewnętrzne ostrzeżenia monitorujące podwyższone błędy. Śledztwo zaczyna się natychmiast. * * * 06: 36 - 07: 15 * * * Inżynierowie najpierw badają aktualizację konfiguracji ~ 06: 00, jedyną znaną zmianę poziomu aplikacji z ściśle dopasowanym czasem. Jest to wykluczone, a uwaga zwraca się do warstwy web / proxy. * * * 06: 52 * * - Okno toczenia patch trwa i wadliwy pakiet jest aktywowany na dodatkowych serwerach. Wpływ zwiększa się wraz z ponownym uruchomieniem serwerów na wadliwą wersję nginx, podczas gdy serwery, które pobrały poprawiony pakiet Ubuntu pozostają zdrowe. * * * 06: 55 * * - Pozostałe aktualizacje serwera WWW przy użyciu poprawionego pakietu Ubuntu i pozostaje zdrowe w całym, nadal służyć jego udział ruchu prawidłowo. * * * 07: 18 - 07: 19 * * - Dotknięte serwery WWW są ponownie uruchamiane jako próba łagodząca. To nie ma wpływu, ponieważ wadliwy pakiet nginx pozostaje zainstalowany. * * * 07: 20 - 07: 55 * * - Serwery podejrzanych są usuwane z rotacji load- balancer. Objawy utrzymują się, ponieważ usługi logowania i środowiska aplikacji są niezależnie dotknięte, co znacznie poszerza wyszukiwania. * * * 07: 41 * * - Wzór korupcji URL jest identyfikowany w dziennikach aplikacji. * * * 07: 45 - 08: 00 * * - Testowanie serwera Per- izoluje wadliwe serwery. Jedyną różnicą od zdrowych serwerów jest wersja pakietu nginx. Wadliwa budowa jest dopasowana do opublikowanego przez Ubuntu zawiadomienia o regresji i poprawionego pakietu. * * * 08: 02 - 08: 11 * * - Skorygowany pakiet jest zainstalowany na wszystkich serwerach. Wskaźnik błędów natychmiast wraca do normy na każdym serwerze, gdy ponownie uruchamia się na stałą wersję. Ostateczne dotknięte środowisko powraca do normy o * * 08: 11 - INCIDENT FULY RESOLVED * *. * * * 08: 11\ + * * - Pełna weryfikacja jest zakończona: każdy serwer jest indywidualnie testowany, a API, deska rozdzielcza, login i środowiska produkcyjne są potwierdzone zdrowe. # # Why resolution took ~ 95 minutes from alert Wykrywanie było szybkie, ale trzy czynniki spowolniły diagnozę. Po pierwsze, rutynowa zmiana konfiguracji wcześniej tego ranka była jedyną znaną zmianą w środowisku i musiała zostać wykluczona - automatyczne łatanie systemu operacyjnego nie pojawia się w dzienniku zmian poziomu aplikacji. Po drugie, awaria została przerwana z natury: niezmienione serwery nadal działają normalnie, a nawet dotknięte serwery skutecznie obsługiwały typy zapytań, których zasady routingu nie zostały naruszone. Po trzecie, usunięcie podejrzanych serwerów z obrotu nie zatrzymało błędów - ponieważ inne poziomy były niezależnie dotknięte - co początkowo wskazywało na to, że dochodzenie zostało oddalone od tych serwerów. # What we are changing * * 1. Etap działania systemu systemów zabezpieczeń przed produkcją. * * Automatyczne aktualizacje bezpieczeństwa OS- i nginx- poziom, w tym krytyczne łaty, zostaną najpierw zainstalowane na serwerach nieprodukcyjnych. Automatyczne walidacja poziomu aplikacji będzie wykonywać reprezentatywne API, deska rozdzielcza i ścieżki logowania do zaktualizowanych serwerów, zanim te same wersje pakietów będą mogły wtoczyć się do produkcji. Rozpoczęcie produkcji rozpocznie się dopiero po przejściu tych kontroli. * * 2. Szybsza diagnoza poziomu version-. * * Nasze książki startowe zawierają teraz natychmiastowe porównanie wersji pakietów i ponowne uruchomienie historii na serwerach, gdy serwery skonfigurowane identycznie zachowują się inaczej.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 26 czerwca 2026 15:47 UTCmonitoring

   We are seeing a degraded performance with FedEx API, some customers reported issues with booking FedEx shipments. We are actively monitoring the situation and will provide updates as soon as more information becomes available or the issue is resolved.

2. 26 czerwca 2026 20:49 UTCresolved

   Resolved by FedEx

1. 19 czerwca 2026 15:38 UTCmonitoring

   We are seeing a degraded performance with USPS Endicia web services. We will continue to monitor as USPS Endicia works to resolve this. https://status.endicia.com

2. 20 czerwca 2026 02:17 UTCresolved

   This incident has been resolved.

1. 18 maja 2026 18:21 UTCidentified

   PrintNode is currently experiencing issues. Some regions may be experiencing degraded performance when attempting to print. See https://www.printnode.com/en/status for details.

2. 18 maja 2026 21:43 UTCresolved

   Resolved by PrintNode.

1. 23 lutego 2026 20:12 UTCidentified

   We are seeing a degraded performance with FedEx web services, some customers reported issues with booking shipments. FedEx has acknowledged an issue on their end. We are actively monitoring the situation and will provide updates as soon as more information becomes available or the issue is resolved.

2. 24 lutego 2026 22:52 UTCresolved

   Resolved by FedEx.

1. 20 października 2025 20:37 UTCinvestigating

   Amazon Web Services had a major outage today that effected a large number software services across the internet, including ShipHawk. While ShipHawk's software did not go down, the outage has led to intermittent reliability for many parcel and LTL carriers regarding rating and label generation. We are working with AWS to resolve these issues as soon as possible. https://health.aws.amazon.com/health/status

2. 20 października 2025 20:56 UTCmonitoring

   Amazon Web Services had a major outage today that effected a large number software services across the internet, including ShipHawk. While ShipHawk's software did not go down, the outage has intermittently affected some carriers regarding rating and label generation. Everything is working currently and we are working with AWS to ensure system responsiveness. https://health.aws.amazon.com/health/status

3. 20 października 2025 23:28 UTCresolved

   The AWS issue affecting carriers has been resolved.

1. 10 października 2025 17:51 UTCinvestigating

   We are seeing a degraded performance with USPS Endicia web services. We will continue to monitor as USPS Endicia works to resolve this. https://status.endicia.com

2. 10 października 2025 18:18 UTCresolved

   Resolved by USPS Endicia

1. 29 września 2025 18:05 UTCidentified

   Customers using WWEX / SpeedShip integrations may experience issues with rating and booking shipments due to an outage of the WWEX / SpeedShip API. The provider has notified us that they are actively working on a resolution. We will continue monitoring and provide updates as they become available.

2. 29 września 2025 22:40 UTCresolved

   Confirmed as resolved by WWEX.

1. 20 czerwca 2025 13:30 UTCidentified

   PrintNode is currently experiencing connectivity issues. Some regions may be experiencing degraded performance when attempting to print. See https://www.printnode.com/en/status for details.

2. 20 czerwca 2025 13:42 UTCidentified

   Connectivity was restored to normal approximately 7 minutes ago; we are monitoring the situation and will post further information if and when it becomes available.

3. 20 czerwca 2025 17:21 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 21 czerwca 2025 04:07 UTCresolved

   This incident has been resolved.

1. 5 maja 2025 17:27 UTCidentified

   Pitney Bowes has notified us they are experiencing technical issues with PB Expedited Delivery Services. Customers who use Pitney Bowes may experience slowness or unavailability of Pitney Bowes shipping rates or printing labels. We will continue to monitor their progress as they resolve this issue. For additional information use Pitney Bowes status page - https://status.pitneybowes.com

2. 6 maja 2025 23:10 UTCresolved

   This incident has been resolved.

1. 14 kwietnia 2025 20:24 UTCinvestigating

   We are currently investigating an issue affecting one of our WMS environments. A subset of customers may be unable to access the system. Our team is actively working to identify the root cause and restore full access as soon as possible. We will continue to provide updates as we make progress. Thank you for your understanding and patience.

2. 14 kwietnia 2025 20:34 UTCmonitoring

   The affected WMS environment is now back online, and system access has been restored for impacted customers. We are currently monitoring the environment to ensure stability.

3. 14 kwietnia 2025 20:47 UTCresolved

   This incident has been resolved.

1. 11 marca 2025 11:52 UTCinvestigating

   Some customers are experiencing slowness with the rating API. Our team is actively investigating the issue. We will provide updates as we learn more.

2. 11 marca 2025 12:00 UTCmonitoring

   The issue causing slowness in the rating API has been identified and resolved.

3. 11 marca 2025 22:34 UTCresolved

   This incident has been resolved.

1. 30 stycznia 2025 13:42 UTCidentified

   Pitney Bowes has notified us they are experiencing technical issues with PB Expedited Delivery Services. Customers who use Pitney Bowes may experience slowness or unavailability of Pitney Bowes shipping rates or printing labels. We will continue to monitor their progress as they resolve this issue. For additional information use Pitney Bowes status page - https://status.pitneybowes.com

2. 30 stycznia 2025 15:59 UTCresolved

   Resolved by Pitney Bowes

1. 25 lipca 2024 17:53 UTCidentified

   We are seeing a degraded performance with UPS web services. We will continue to monitor as UPS works to resolve this. To see current response times from UPS you can check: - https://downdetector.com/status/ups/ - https://www.shippingapimonitor.com/history.html?api=ups

2. 25 lipca 2024 20:00 UTCmonitoring

   UPS resolved the issue on their side, we will continue to monitor it.

3. 26 lipca 2024 00:14 UTCresolved

   This incident has been resolved.

1. 18 czerwca 2024 17:03 UTCidentified

   USPS Endicia has noted that they have fixed the postage printing issue. See USPS Endicia status page for more details: https://status.endicia.com/

2. 18 czerwca 2024 23:19 UTCresolved

   Resolved by Endicia.

1. 17 czerwca 2024 16:01 UTCidentified

   We are seeing a degraded performance with FedEx web services. We will continue to monitor as FedEx works to resolve this. To see current response times from FedEx you can check: https://www.shippingapimonitor.com/history.html?api=fedex

2. 18 czerwca 2024 17:01 UTCresolved

   Resolved by FedEx.

1. 22 maja 2024 17:46 UTCidentified

   We are seeing a degraded performance with FedEx web services. We will continue to monitor as FedEx works to resolve this. To see current response times from FedEx you can check: https://www.shippingapimonitor.com/history.html?api=fedex

2. 22 maja 2024 20:20 UTCresolved

   Resolved by FedEx team.

1. 17 maja 2024 19:18 UTCidentified

   We are seeing a degraded performance with UPS web services. We will continue to monitor as UPS works to resolve this. To see current response times from UPS you can check: - https://downdetector.com/status/ups/ - https://www.shippingapimonitor.com/history.html?api=ups

2. 17 maja 2024 22:41 UTCresolved

   Resolved by UPS.