Shiphawk driftsforstyrrelser

1. 2. september 2026 kl. 16.24 UTCmonitoring

   FedEx webtjenester oplever i øjeblikket forringet ydeevne, og nogle kunder har rapporteret problemer booking FedEx forsendelser. Vi vil fortsat overvåge situationen, mens FedEx arbejder på at løse problemet. Nuværende FedEx svartider er tilgængelige her: https: / / www.shippingapimonitor.com / histori.html? api = fedex

2. 2. september 2026 kl. 21.59 UTCresolved

   Opløst på FedEx side.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 25. august 2026 kl. 14.10 UTCinvestigating

   Nogle kunder oplever langsommelighed med WMS adgang. Vores team undersøger sagen aktivt.

2. 25. august 2026 kl. 16.01 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

3. 25. august 2026 kl. 17.40 UTCresolved

   Denne hændelse er blevet løst. Vi deler flere detaljer, så snart de er tilgængelige.

4. 27. august 2026 kl. 22.21 UTCpostmortem

   # # efter-hændelsesrapport: WMS sløvhed og fejl for huse på One Database instance - 25. august 2026 * * Status: * * Opløst * * Tilfælde vindue: * * August 25, 2026, ~ 04: 30 - 08: 45 PDT\ (07: 30 - 11: 45 ET\) * * Påvirkede: * * Kunder hvis databaser er hostet på en WMS database instans i vores US- East lager gruppe: side belastning gange op til 20x normal, og intermitterende fejl på scanner og admin skærme i den værste periode. * * Ikke påvirket: * * Alle andre WMS database instanser og lagergrupper, TMS platform, dataintegritet\ (ingen transaktion blev tabt, duplikeret, eller delvist anvendt\), og alt afsluttet arbejde - hver transaktion, der blev accepteret blev behandlet korrekt. Blev du påvirket? Virkningen var begrænset til kunder, hvis WMS databaser er hostet på en specifik database instans i vores US- East lager gruppe, og kun om morgenen i august 25\ (ca. 04: 30 - 08: 45 PDT / 07: 30 - 11: 45 ET\). Hvis du ikke så langsomme sidebelastninger i WMS under dette vindue, var dit miljø ikke involveret. Alle andre WMS database instanser og lagergrupper, og hele TMS platform, drives normalt i hele. # # # Oversigt På aftenen i august 24, en tredjeparts ETL service, der kopierer ShipHawk data i vores data lager genstartet en stor del af sin sync job på én gang mod en af vores produktion databaser. Hver genstartet job begyndte at genlæse en efterslæb af historiske ændringer data med fuld hastighed, parallelt og uden nogen sats begrænsning. Læs volumen klatrede til omkring fem gange den forventede top og forbrugt det meste af disk båndbredde til rådighed for denne database instans. Dette begyndte fra den ene dag til den anden, når lageraktiviteten er let, så det havde ingen indvirkning på driften på det tidspunkt. Når US- East morgen skift startede den 25. august, normale WMS aktivitet blev tilføjet oven på den allerede mættede kanal og instansen nåede sin båndbredde grænse. Ud fra ansøgningen synspunkt dette syntes som langsom database svar: forespørgsler, der normalt vender tilbage i millisekunder tog langt længere tid, arbejde i kø op bag dem, og sider indlæses langsomt. Hvis et databasesvar oversteg ansøgningstidspunktet, returnerede siden en fejl i stedet for at indlæse. Tjenesten har været operationel hele tiden. På tværs af de berørte instans, kunder behandlet omkring 70% af volumen normalt håndteres i dette vindue\ (picks, pakker og inventar flytter\), selv om oplevelsen var langsom og til tider vanskeligt at arbejde med, og graden af effekt varierede mellem kunderne. Situationen løst ved at tilbagekalde ETL-tjenestedatabasens akkreditiver helt på 08: 37 PDT. Databasen er fundet inden for otte minutter. Forsinket arbejde skyllede igennem de følgende to timer, og alle berørte lagre var tilbage til normalt tempo. Ingen kunde handling var eller er påkrævet, og ingen data blev påvirket. Ingen transaktion blev tabt, duplikeret, eller delvist anvendt - vi verificerede dette mod integration logs dækker hele hændelsesvinduet. Arbejde, der blev indsendt enten korrekt eller mislykkedes rent før nogen ændring. Dette behandles mere detaljeret nedenfor. # # Hvad blev påvirket Virkningen var begrænset til kunder, hvis databaser er hostet på den berørte WMS database instans i US- East lager gruppen. Under hele hændelsesvinduet var systemet langsomt over hele brættet - scanner og admin sider, der normalt indlæse i godt under et sekund tog mange gange længere - og hvor en database respons oversteg programmet timeout, siden returnerede en fejl snarere end indlæsning. Hvordan det så ud i praksis: * * Lageret gulv: * * scanner sider\ (picking, flytte, justering opgørelse\) indlæst meget langsomt; en arbejdstager, der genprøvede, mens en side sad fast kunne modtage en fejl side og nødt til at gå tilbage og gentage handlingen. * * Fejl blev koncentreret i et enkelt udbrud snarere end spredt over hændelsen. * * De fleste faldt inden for et 15-minutters vindue på toppen af trængslen\ (06: 15 - 06: 30 PDT\). Counting bekræftede fejlsider i vores web- server og program logs, den mest berørte lager så 71 i dette vindue. * * Systemet forblev oppe hele vejen. * * Hver indsendt transaktion enten afsluttet korrekt eller mislykkedes rent, før du foretager nogen ændring. Under den dybeste afmatning vindue kan vi vise hundredvis af transaktioner fuldføre med succes for de brugere, der fortsatte med at arbejde. Hvad var IKKE påvirket * * Dataintegritet. * * Fejlene opstod ved begyndelsen af anmodningsbehandlingen, før der blev foretaget nogen ændring. Ingen transaktion blev tabt, duplikeret eller delvist anvendt. Hver opfyldelse, opgørelse flytte, og forsendelse udstationering, der er afsluttet gjorde det korrekt - vi verificerede integration logs for hændelsen vindue. * * Bestil og forsendelse synkronisering til ERP 'er og markedspladser * * udfyldes korrekt i hele; indlæg, der er i kø under opbremsning blev leveret i fuld under catch- up\ (verificeret i integration logs - ingen mislykkede indlæg\). * * Alle andre miljøer. * * De andre databaser og hele TMS-platformen fungerer normalt. * * Sikkerhed og leje. * * Ingen sikkerhedsgrænse var involveret på noget tidspunkt. Den pågældende tredje part tjeneste er en dataintegrationsleverandør, der opererer under legitimation, vi udstedte; spørgsmålet var omfanget af sine læsning, ikke nogen uautoriseret adgang. # # # Timeline\ (alle gange PDT; tilføje 3 timer til ET\) ; tid ECB 's Styrelsesråd ; 24 aug. 22: 54 - 22: 57 Hver begynder at genlæse historiske ændring data med fuld hastighed. ; 24 aug, 22: 54 - 23: 50 Overnatning lager trafik er let, så der er ingen customer-synlig effekt endnu. ; 25. aug, ~ 04: 30 Kombineret efterspørgsel overstiger den reducerede netværkshastighed; køer starter bygning og de første sider begynder at gøre langsommere end normalt. Mead124; 05: 30 Mead124; Automatiseret svartid overvågning indberetninger som lager aktivitet ramper op; kundemeldinger om langsommelighed ankommer i samme periode. Undersøgelsen begynder. Meak overbelastning: databaseforbindelser spike til ~ 15x normal som anmodninger hobe op; bølgen af scanner- skærm fejl sker\ (06: 15- 06: 30\).; ; 06: 50; Root årsag identificeret: disk båndbredde over instance grænse; sælgers replikation streams identificeret som føreren. ; 124; 07: 00 ; 07: 20 - 08: 30 I denne periode starter den yderligere job.; • 124; 08: 35 • 124; • ETL 's database er låst og dens sessioner afsluttet en sidste gang. • 124; ; 08: 38 - 08: 45; Database køer dræn; side responstid vende tilbage til normal. Kundesammenstødet slutter. # # Hvorfor resolution tog ~ 3 timer fra første rapporter Tre faktorer udvidede tidslinjen. Først skete aftrækkeren syv timer før symptomerne. ETL-tjenestens genoplæsning løb fra den ene dag til den anden og havde allerede forbrugt den tilgængelige båndbredde, men med lagerets aktivitetslampe på det tidspunkt skabte begrænsningen kun en lille ændring i systemets responstider - under vores varslingstærskelværdier - så det gik uopdaget. Vores automatiserede overvågning gjorde alarm, når lager aktivitet ramped op om morgenen, men på det tidspunkt den underliggende ændring var syv timer gammel, og der var ingen nylig implementering eller konfiguration ændring til punkt til. For det andet, ETL-tjenestens replikation læser er usynlige for standard database forespørgsel logs - de bruger en replikation protokol snarere end forespørgsler - så identificere dem som forbrugeren krævede korrelerende disk, netværk, og connection- niveau bevis. For det tredje er ETL-tjenesten bygget for at overleve afbrydelser: pause i sine job og terminering af sine forbindelser både mislykkedes som lempelser, fordi det genopretter automatisk inden for få sekunder, og det genstartet yderligere job, mens vi pauser andre. Kun at tilbagekalde dens legitimation stoppede den. # # Hvad vi ændrer * * Tunning WMS svar- tid varslingstærskelværdier. * * Betingelsen bag denne hændelse var til stede i syv timer natten over, men under lys belastning flyttede det responstider for lidt til at krydse vores varslingstærskelværdier - så den første alarm kom kun, når lageraktivitet rampet op og kunderne allerede var ramt. Vi justerer disse tærskler for at være følsomme over for mindre skift i WMS responstid, herunder ved lav belastning, så begivenheder som dette er fanget og handlet på, før de når kunderne. Dette omfatter alarmering på de specifikke ledende indikatorer for denne hændelse - disk båndbredde forbrug og disk kø dybde. * * Databasen er blevet migreret til en instans type med betydeligt mere disk båndbredde * *, hvilket giver betydelig headroom over spidsbelastning efterspørgsel for at absorbere pigge af denne art. * * Vi fortsætter vores undersøgelse med ETL sælger. * * Vi har en åben sag med dem søger en forklaring på den samtidige job genstart, og kræver sats begrænsning og concurrency hætter for genlæsning mod kunde kilder. Det arbejde er i gang.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 20. august 2026 kl. 14.06 UTCinvestigating

   Vi har modtaget rapporter om, at TMS WebPortal returnerer fejl eller undlader at indlæse for nogle kunder. Vi er aktivt undersøge problemet og vil give opdateringer som mere information bliver tilgængelig.

2. 20. august 2026 kl. 15.02 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 20. august 2026 kl. 15.16 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

4. 20. august 2026 kl. 18.06 UTCresolved

   Denne hændelse er blevet løst.

5. 20. august 2026 kl. 19.35 UTCpostmortem

   # Post- hændelse rapport: Forhøjede API og Login fejl - August 20, 2026 * * Status: * * Opløst * * Tilfælde vindue: * * August 20, 2026, 06: 31 - 08: 11 PDT\ (13: 31 - 15: 11 UTC\) * * Påvirkede: * * ShipHawk API og dashboard anmodninger i delte produktionsmiljøer, plus login service. Virkningen var delvis snarere end en fuldstændig afbrydelse: ca. 25% af den samlede API-trafik på [shiphawk.com] (http: / / shiphawk.com) mislykkedes under det berørte vindue; antallet af fejl inden for de berørte miljøer varierede fra ca. 37% til 48%, og omkring 41% af anmodninger om logintjenester mislykkedes. * * Ikke påvirket: * * In-Cart rating\ (og alle / api / v4 / satser anmodninger\), baggrundsbehandling\ (alle planlagte job, skrive tilbage, webkroge, async label generation, tracking og carrier kommunikation kørte normalt\), dataintegritet. # # Summary Om morgenen den 20. august, en operating- system kritisk sikkerhedsopdatering offentliggjort af Ubuntu - og anvendes automatisk af vores standard patching proces - indeholdt en defekt i web server komponent\ (nginx\), der sidder foran ShipHawk ansøgning. Den berørte pakke blev offentliggjort den 19. august som [USN- 8563-3] (https: / / ubuntu.com / security / notits / USN- 8563-3). Ubuntu bekræftede, at denne opdatering indførte en regression og offentliggjorde [USN-8563-4] (https: / / ubuntu.com / security / notits / USN-8563-4) samme dag, hvilket vendte den problematiske ændring, indtil der blev foretaget yderligere undersøgelser. Mens den defekte version kørte, proxy lag ødelagt URL for mange indgående anmodninger, før du giver dem til programmet. Ansøgningen kunne ikke matche de beskadigede URL 'er til nogen kendt endpoint og svarede * * 404 Ikke fundet * *. Fejlene var umiddelbare, rene afslag: ingen anmodning blev delvist behandlet, omdirigeret til den forkerte konto, eller tabt efter accept. Vores servere ikke alle downloade og installere operating- system sikkerhedsopdateringer på samme tidspunkt; opdatere kontrol og installation vinduer er spredt på tværs værter. Som et resultat, nogle servere downloadede den defekte nginx build før Ubuntu offentliggjort den korrigerede pakke, mens andre kontrolleres senere og downloades den korrigerede build direkte. Kun de servere, der allerede havde downloadet den defekte pakke blev påvirket, når deres planlagte installation kørte. Dette er grunden til problemet syntes intermitterende: otherwise- identiske anmodninger kunne mislykkes eller lykkes afhængigt af hvilken server håndterede dem. Selv på servere, der kører den defekte nginx pakke, kun en delmængde af anmodninger mislykkedes. Regressionen påvirkede specifikke nginx routing regler snarere end hele proxy konfiguration, så mange URL-mønstre fortsatte med at arbejde normalt på en berørt server. Hændelsen blev helt løst ved 08: 11 PDT efter hver berørt server blev opgraderet til den korrigerede pakke og verificeret sund. Ingen kunde handling var eller er påkrævet. # Hvad blev påvirket Tallene nedenfor tæller * * kun fejl forårsaget af denne hændelse * *. Almindelige 404 svar\ (opslag af poster, der virkelig ikke findes, ugyldige URL 'er, bot trafik\) blev identificeret ved deres særskilte svar signatur og udelukket. 124; miljø 124; anvendelsesområde 124; indtrykket af vindue\ (PDT\) --- 124; --- 124; --- 124; --- 124; --- 124; --- 124; 124; sh- p-1 environment = 124; Login-service = 124; Begge servere = 124; 06: 33 - 08: 08; 124; 124; sh- p-2 environment 124; sh- p-3 environment Name Hvordan det så ud i praksis: * * * API-integration * * modtaget HTTP 404 svar for gyldige anmodninger. Fordi fiaskoer var umiddelbare og statsløse, kunde forsøg kunne lykkes, når de landede på en upåvirket server. * * * Dashboard og login * * sider undlod at indlæse eller logge ind periodisk. * Fejl afhang af den nøjagtige URL: nogle anmodninger typer passeret gennem upåvirket selv på defekte servere, tilføje til den periodiske udseende. Hvad var IKKE påvirket * * * Anmodninger om bedømmelse af vogne. * * Alle anmodninger om rating fra webportalen, e-handelsplatforme, ERP-platforme og regelmæssige API-anmodninger om "/ api / v4 / satser" fungerede som sædvanlig. * * * Baggrundsjob blev slet ikke berørt. * * Alle asynkron behandling - planlagte job, skrive tilbage, opgørelse sync, webhook leverancer, dokument og etiket generation, carrier og ERP kommunikation - kører bag proxy lag og fortsatte normalt under hele hændelsen. Intet arbejde i kø blev tabt eller forsinket. * * * Dataintegritet. * * Ingen data blev tabt, ændret eller ødelagt. Anmodninger, der enten er afsluttet normalt eller afvist direkte. * * * Sikkerhed og leje. * * Ingen anmodning blev sendt til en anden konto, og ingen sikkerhedsgrænse blev overskredet. Korruptionen fandt sted efter al adgangskontrol blev gennemført. Den underliggende Ubuntu opdatering var en forebyggende sikkerhed patch; den sårbarhed, det behandlet blev ikke udnyttet på vores systemer. # # Timeline\ (alle gange PDT, 20 August, 2026\) * * * Aug 19\ (day\) * * - Ubuntu offentliggør en sikkerhedsopdatering for nginx; en defekt er rapporteret, og Ubuntu udgiver en korrigeret pakke samme dag. Den korrigerede version spredes til offentlige opdateringsspejle natten over. * * * Aug 19, 18: 24 - 23: 09 * * - Den natlige opdatering kontrol på de sid- berørte servere downloade dagens nginx opdatering. I disse øjeblikke er den defekte bygning stadig den nyeste på spejlene. Dette trin downloader kun pakken; installationen sker i løbet af næste morgens patch vindue. * * * Aug 20, 04: 12 - 05: 05 * * - En anden gruppe servere kører sin natlige opdatering check efter den korrigerede bygge har nået spejlene. Disse servere downloade den faste version og forblive sunde under hele hændelsen. * * * ~ 06: 00 * * - En rutine, ikke-relateret programkonfiguration opdatering anvendes til kommende udgivelser. Det har ingen effekt på i øjeblikket frigivet funktionalitet og * * spiller ingen rolle i hændelsen * *, men fordi det er den eneste kendte ændring den morgen, bliver det den første mistanke, når fejl vises. * * * 06: 00 * * - Det natligt automatiserede klappevindue begynder at rulle nginx opdateringer på tværs af miljøer. Nogle servere har allerede den korrigerede pakke downloadet, mens andre har den defekte pakke. * * 06: 31 - 06: 34 - UDENRIGSSTART. * * Som rullende automatiseret patch vinduet skrider fremad, er den tidligere downloadede defekt nginx pakke installeret på flere web-og login-servere på tværs af delte produktionsmiljøer. Fordi patch tidsplaner er forskudt, ikke alle servere opdatere på én gang, og nogle servere forbliver sunde. De første customer-face mislykkedes anmodninger begynder på * * 06: 31 * *. * * 06: 35 * * - Automatiserede eksterne overvågningsindberetninger om forhøjede fejl. * * Undersøgelsen begynder med det samme. * * * * 06: 36 - 07: 15 * * - Ingeniører først undersøge ~ 06: 00 konfiguration opdatering, den eneste kendte application- niveau ændring med tæt matchende timing. Det er udelukket, og opmærksomheden vender sig mod web / proxy lag. * * 06: 52 * * - Vinduet til rullende patch fortsætter og den defekte pakke aktiveres på yderligere servere. Virkningen stiger som mere berørte servere genstarte på den defekte nginx version, mens servere, der downloadede Ubuntu 's korrigerede pakke forbliver sunde. * * 06: 55 * * - En resterende webserver opdateringer ved hjælp af Ubuntu 's korrigerede pakke og forbliver sunde hele, fortsætter med at tjene sin andel af trafikken korrekt. * * 07: 18 - 07: 19 * * - Berørte webservere genstartes som et afbødende forsøg. Dette har ingen effekt, fordi den defekte nginx pakke forbliver installeret. * * 07: 20 - 07: 55 * * - Mistænkte servere fjernes fra load- balancer rotation. Symptomer vedvarer, fordi login service og applikation miljøer er uafhængigt påvirket, som materielt udvider søgningen. * * 07: 41 * * - Url-korruption mønster er identificeret i ansøgningen logfiler. * * * 07: 45 - 08: 00 * * - Per- server test isolerer de defekte servere. Den eneste forskel fra sunde servere er nginx pakke version. Den defekte bygning er matchet til Ubuntu 's offentliggjorte regression varsel og korrigeret pakke. * * 08: 02 - 08: 11 * * - Den korrigerede pakke er installeret på tværs af alle berørte servere. Fejlhastigheder vender tilbage til normal straks på hver server, som det genstarter på den faste version. Det endelige berørte miljø vender tilbage til normal ved * * 08: 11 - INCIUTIS FULDT RESOLVERET * *. * * 08: 11\ + * * - Fuld verifikation er afsluttet: Hver server er individuelt testet, og API, dashboard, login, og produktionsmiljøer er bekræftet sunde. # Hvorfor opløsning tog ~ 95 minutter fra alarm Detektering var hurtig, men tre faktorer bremsede diagnosen. For det første, en rutinemæssig konfiguration ændring tidligere på morgenen var den eneste kendte ændring i miljøet og måtte udelukkes - automatiseret OS patching vises ikke i nogen ansøgning-niveau ændring log. For det andet, fejlen var intermitterende af natur: uberørte servere fortsatte med at tjene normalt, og selv berørte servere med held håndterede anmodninger typer, hvis routing regler ikke blev påvirket. For det tredje standsede fjernelsen af de mistænkte servere fra rotation ikke fejlene - fordi andre niveauer blev påvirket uafhængigt - som oprindeligt pegede undersøgelsen væk fra disse servere. # Hvad vi ændrer * * 1. Stage operating- system sikkerhed patches før produktionen. * * Automatiserede OS- og nginx- niveau sikkerhedsopdateringer, herunder kritiske patches, vil først blive installeret på non- produktion servere. Automatisk applikation- niveau validering vil udøve repræsentative API, dashboard, og login stier mod de opdaterede servere, før de samme pakkeversioner er tilladt at rulle i produktionen. Udrulningen af produktionen begynder først, når kontrollen er afsluttet. * * 2. Hurtigere version- niveau diagnose. * * Vores hændelsesrunbooks omfatter nu øjeblikkelig sammenligning af pakkeversioner og genstarte historien på tværs af servere, når identiske-konfigurerede servere opfører sig anderledes.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 26. juni 2026 kl. 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. juni 2026 kl. 20.49 UTCresolved

   Resolved by FedEx

1. 19. juni 2026 kl. 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. juni 2026 kl. 02.17 UTCresolved

   This incident has been resolved.

1. 18. maj 2026 kl. 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. maj 2026 kl. 21.43 UTCresolved

   Resolved by PrintNode.

1. 23. februar 2026 kl. 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. februar 2026 kl. 22.52 UTCresolved

   Resolved by FedEx.

1. 20. oktober 2025 kl. 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. oktober 2025 kl. 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. oktober 2025 kl. 23.28 UTCresolved

   The AWS issue affecting carriers has been resolved.

1. 10. oktober 2025 kl. 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. oktober 2025 kl. 18.18 UTCresolved

   Resolved by USPS Endicia

1. 29. september 2025 kl. 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. september 2025 kl. 22.40 UTCresolved

   Confirmed as resolved by WWEX.

1. 20. juni 2025 kl. 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. juni 2025 kl. 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. juni 2025 kl. 17.21 UTCmonitoring

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

4. 21. juni 2025 kl. 04.07 UTCresolved

   This incident has been resolved.

1. 5. maj 2025 kl. 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. maj 2025 kl. 23.10 UTCresolved

   This incident has been resolved.

1. 14. april 2025 kl. 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. april 2025 kl. 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. april 2025 kl. 20.47 UTCresolved

   This incident has been resolved.

1. 11. marts 2025 kl. 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. marts 2025 kl. 12.00 UTCmonitoring

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

3. 11. marts 2025 kl. 22.34 UTCresolved

   This incident has been resolved.

1. 30. januar 2025 kl. 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. januar 2025 kl. 15.59 UTCresolved

   Resolved by Pitney Bowes

1. 25. juli 2024 kl. 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. juli 2024 kl. 20.00 UTCmonitoring

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

3. 26. juli 2024 kl. 00.14 UTCresolved

   This incident has been resolved.

1. 18. juni 2024 kl. 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. juni 2024 kl. 23.19 UTCresolved

   Resolved by Endicia.

1. 17. juni 2024 kl. 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. juni 2024 kl. 17.01 UTCresolved

   Resolved by FedEx.

1. 22. maj 2024 kl. 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. maj 2024 kl. 20.20 UTCresolved

   Resolved by FedEx team.

1. 17. maj 2024 kl. 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. maj 2024 kl. 22.41 UTCresolved

   Resolved by UPS.