55 incidente Shiphawk înregistrate începând din februarie 2021, cu actualizări oficiale, componente afectate, durată și informații despre rezolvare.
Serviciile web FedEx se confruntă în prezent cu performanțe degradate, iar unii clienți au raportat probleme de rezervare a transporturilor FedEx. Vom continua să monitorizăm situația în timp ce FedEx lucrează pentru a rezolva problema. A se vedea nota de subsol 1
Rezolvat pe partea FedEx.
Traducere automată din actualizarea oficială a incidentului.
Unii clienți se confruntă cu lentoare cu accesul WMS. Echipa noastră investighează în mod activ problema.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat. Vom împărtăși mai multe detalii de îndată ce acestea sunt disponibile.
## Post-Incident Report: WMS Slowness and Errors for Warehouses on One Database Tribunal - August 25, 2026 **Status:** Rezolvat **Incident window:** August 25, 2026, ~04:30 - 08:45 PDT \(07:30 - 11:45 ET\) ** Affected:** Clientii ale caror baze de date sunt gazduite pe o baza de date WMS instant in grupul nostru depozit SUA-Est: pagina de timp de incarcare de pana la 20x normale, si erori intermitente pe ecrane scaner si admin in cea mai proasta perioada. ** Neafectat: ** Toate celelalte cazuri de baze de date WMS și grupuri de depozit, platforma TMS, integritatea datelor \(nicio tranzacție a fost pierdută, duplicată sau parțial aplicată\) și toate lucrările finalizate - fiecare tranzacție acceptată a fost procesată corect. Ai fost afectat? Impactul a fost limitat la clienţii ale căror baze de date WMS sunt găzduite într-o anumită bază de date în grupul nostru depozit SUA-Est, şi numai în dimineaţa zilei de 25 august \ (aproximativ 04:30 - 08:45 PDT / 07:30 - 11:45 ET\). Dacă nu ați văzut sarcini de pagină lentă în WMS în timpul acelei ferestre, mediul dumneavoastră nu a fost implicat. Toate celelalte cazuri de baze de date WMS și grupuri de depozite, precum și întreaga platformă TMS, au funcționat în mod normal pe tot parcursul. ### Rezumat În seara zilei de 24 august, un serviciu ETL terţ care copiază datele ShipHawk în depozitul nostru de date a repornit un lot mare de locuri de muncă sincronizate simultan cu una dintre bazele noastre de date de producţie. Fiecare loc de muncă repornit a început să recitească un backlog de date istorice de schimbare la viteză maximă, în paralel și fără nicio limitare a ratei. Volumul de citire a urcat la aproximativ de cinci ori mai mare decât vârful preconizat și a consumat cea mai mare parte a benzii de bandă disk disponibile pentru această instanță de bază de date. Acest lucru a început peste noapte, când activitatea depozitului este uşoară, aşa că nu a avut nici un efect asupra operaţiunilor la momentul respectiv. Când tura de dimineață SUA-Est a început pe 25 august, activitatea normală WMS a fost adăugată pe partea de sus a canalului deja saturat și cazul a atins limita de lățime de bandă. Din punctul de vedere al aplicației, acest lucru a apărut ca răspunsuri lente în baza de date: întrebări care în mod normal se întorc în milisecunde a durat mult mai mult, lucru la coadă în spatele lor, și pagini încărcate lent. În cazul în care un răspuns la o bază de date a depășit timeout-ul aplicației, pagina a returnat o eroare în loc de încărcare. Serviciul a rămas operațional pe tot parcursul. De-a lungul cazului afectat, clienții au procesat aproximativ 70% din volumul manipulat în mod normal în acea fereastră \ (picks, pachete și mișcări de inventar\), deși experiența a fost lentă și uneori dificil de lucrat cu, și gradul de impact a variat între clienți. Situația a fost soluționată prin revocarea acreditării bazei de date a serviciului ETL la 08:37 PDT. Baza de date recuperat în opt minute. Munca întârziată a trecut prin următoarele două ore, şi toate depozitele afectate au revenit la ritmul normal. Nicio acțiune a clientului nu a fost sau este necesară și nu au fost afectate date. Nu s-a pierdut, s-a duplicat sau s-a aplicat parțial - am verificat acest lucru împotriva jurnalelor de integrare care acoperă întreaga fereastră a incidentului. Lucrările depuse fie au fost completate corect, fie au eşuat curat înainte de a face vreo schimbare. Acest lucru este acoperit în detaliu mai jos. ### Ce a fost afectat Impactul s-a limitat la clienții ale căror baze de date sunt găzduite în cazul bazei de date WMS afectate în grupul depozitului SUA-Est. De-a lungul ferestrei incidentului sistemul a fost lent peste bord - scaner și pagini administrative care în mod normal se încarcă bine sub o secundă a durat de multe ori mai mult - și în cazul în care un răspuns de bază de date a depășit termenul de aplicare, pagina a returnat mai degrabă o eroare decât de încărcare. Cum arăta asta în practică: **Warehouse floor:** scanner pages \ (picking, moving, ajusting inventar\) loaded very lowly; a worker who retried while a page was blocked could receive an error page and have to go back and repeat the action. **Eroare au fost concentrate într-o singură explozie, mai degrabă decât răspândit peste incident.** Cele mai multe dintre ele au căzut într-o fereastră de 15 minute la vârful congestiei \(06:15 - 06:30 PDT\). Numărarea de pagini de eroare confirmate în nostru web-server și jurnalele de aplicații, cel mai afectat depozit a văzut 71 în acea fereastră. ** Sistemul a rămas în sus pe tot parcursul.** Fiecare tranzacție depusă fie a efectuat corect, fie a eșuat curat înainte de a face orice modificare. În timpul celei mai adânci ferestre de încetinire putem arăta sute de tranzacții care se încheie cu succes pentru utilizatorii care au continuat să lucreze. Ce nu a fost afectat **Integritatea datelor.** Erorile au avut loc chiar la începutul procesării cererii, înainte de efectuarea oricărei modificări. Nu s-a pierdut, s-a duplicat sau s-a aplicat parțial nicio tranzacție. Fiecare realizare, mutare inventar, și expediere postare care a terminat a făcut atât de corect - am verificat jurnalele de integrare pentru fereastra incident. **Comanda și sincronizare transport la ERP-uri și piețe** completat corect pe tot parcursul; postări care la coadă în timpul încetinirii au fost livrate în întregime în timpul captură-up \ [verificat în jurnalele de integrare - nu postări eșuate\). ** Toate celelalte medii.** Depozitele din celelalte cazuri din baza noastră de date şi întreaga platformă TMS funcţionau normal. **Securitate și închiriere.** Nu a fost implicată nicio limită de securitate. Serviciul terţilor în cauză este un furnizor de integrare a datelor care operează sub acreditarea pe care am emis-o; problema a fost volumul citirilor sale, nu accesul neautorizat. ### Timeline \(all times PDT; adăugați 3 ore pentru ET\) - Da. Fiecare începe recitirea datelor de schimbare istorice la viteza maxima. Traficul peste noapte depozit este ușor, astfel încât nu există nici un efect de client-vizibil încă. 25 aug, ~04:30 Cererea combinată depășește viteza redusă a rețelei; cozile încep să construiască și primele pagini încep să dea mai încet decât în mod normal. Începe investigaţia. În această perioadă începe locuri de muncă suplimentare. @ info: whatsthis Impactul asupra clienților se încheie. ### Why rezolution taken ~3 hour from first reports Trei factori au extins cronologia. În primul rând, declanşatorul a avut loc cu şapte ore înainte de simptome. Re-citirea serviciului ETL a avut loc peste noapte şi a consumat deja lăţimea de bandă disponibilă, dar cu lumina activităţii depozitului la acea oră, constrângerea a produs doar o uşoară schimbare a timpului de răspuns al sistemului - sub pragurile noastre de alertă - aşa că a mers nedetectat. Monitorizarea noastră automată a alertat o dată activitatea depozitului pornit în sus în dimineața, dar până atunci schimbarea de bază a fost vechi de șapte ore și nu a existat nici o implementare recentă sau schimbare de configurație la punctul de la. În al doilea rând, citirile de replicare ale serviciului ETL sunt invizibile jurnalelor de interogare standard ale bazei de date - folosesc un protocol de replicare mai degrabă decât întrebări - astfel încât identificarea lor ca fiind consumatorul necesar corelarea disc, rețea, și dovezi la nivel de conexiune. În al treilea rând, serviciul ETL este construit pentru a supraviețui întreruperilor: întreruperea locurilor de muncă și încetarea conexiunilor sale au eșuat atât ca atenuare, deoarece se reconectează automat în câteva secunde, și a reluat locuri de muncă suplimentare în timp ce ne-am oprit pe alții. Numai revocarea acreditărilor sale a oprit-o. Ce ne schimbăm ** Tuning WMS response-time alert learnes.** Starea din spatele acestui incident a fost prezentă timp de şapte ore peste noapte, dar sub sarcină uşoară s-a mişcat timpul de răspuns prea puţin pentru a trece pragurile noastre de alertă - aşa că prima alertă a venit doar după ce activitatea depozitului a crescut şi clienţii au fost deja afectaţi. Ajustăm aceste praguri pentru a fi sensibile la schimbări mai mici în timpul de răspuns WMS, inclusiv la sarcină mică, astfel încât evenimente ca aceasta sunt capturate și au acționat înainte de a ajunge la clienți. Aceasta include alertarea asupra indicatorilor principali specifici ai acestui incident - consumul de lățime de bandă a discului și adâncimea cozii de disc. **Baza de date a fost migrată către un tip de instanță cu o lățime de bandă mai mare de disc**, oferind o cameră cu cap semnificativ peste cererea de vârf pentru a absorbi vârfuri de acest tip. ** Continuăm investigaţia cu vânzătorul ETL.** Avem un caz deschis cu ei care caută o explicație pentru reluarea simultană a locului de muncă, și care necesită limitări ale ratei și plafonări de contractare pentru re-citiri împotriva surselor clienților. Această lucrare este în curs de desfășurare.
Traducere automată din actualizarea oficială a incidentului.
Am primit rapoarte că TMS WebPortal returnează erori sau nu reușește să încarce pentru unii clienți. Investigăm în mod activ problema și vom oferi actualizări pe măsură ce mai multe informații devin disponibile.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
# Raport post-incident: API ridicat și erori de autentificare - 20 august 2026 **Status:** Rezolvat **Incident window:** August 20, 2026, 06:31 - 08:11 PDT \(13:31 - 15:11 UTC\) ** Affected:** ShipHawk API și cereri de bord în medii de producție comune, plus serviciul de autentificare. Impactul a fost mai degrabă parțial decât o pană completă: aproximativ 25% din traficul total al API pe [shiphawk.com][http://shiphawk.com] a eșuat în timpul ferestrei afectate; ratele de eșec în mediile afectate au variat de la aproximativ 37% la 48% și aproximativ 41% din cererile de autentificare-service au eșuat. ** Neafectat:** Evaluarea In-Cart \ (și toate cererile /api/v4/rates\), procesarea de fond \ (toate locurile de muncă programate, scrie înapoi, site-uri web, generarea de etichete asinc, urmărire și comunicații de transport a fugit în mod normal\), integritatea datelor. ## Rezumat În dimineața zilei de 20 august, o actualizare de securitate critică a sistemului de operare publicată de Ubuntu - și aplicată automat prin procesul nostru standard de patching - conținea un defect în componenta serverului web \(nginx\) care stă în fața aplicației ShipHawk. Pachetul afectat a fost publicat la 19 august ca [USN-8563-3] [https://ubuntu.com/security/notices/USN-8563-3]. Ubuntu a confirmat că această actualizare a introdus o regresie și a publicat [USN-8563-4] [https://ubuntu.com/security/notices/USN-8563-4] în aceeași zi, reluând modificarea problematică în așteptarea unei investigații suplimentare. În timp ce versiunea defectuoasă a fost difuzate, stratul proxy corupt URL-ul multor cereri primite înainte de predarea acestora la aplicație. Aplicația nu a putut potrivi URL-urile corupte cu orice criteriu final cunoscut și a răspuns **404 Negăsit**. Eșecurile au fost imediat, respingeri curate: nicio cerere nu a fost parțial procesată, direcționată către contul greșit sau pierdută după acceptare. Serverele noastre nu descarcă și nu instalează toate actualizările de securitate ale sistemului de operare în același moment; actualizările și instalarea ferestrelor sunt bruiate prin gazde. Ca urmare, unele servere descărcat nginx defect construi înainte de Ubuntu publicat pachetul corectat, în timp ce altele verificate mai târziu și descărcat corect construi direct. Numai serverele care au descărcat deja pachetul defect au fost afectate atunci când instalarea lor programată a fugit. Acesta este motivul pentru care problema a apărut intermitent: cererile de altă identitate ar putea eșua sau reuși în funcție de care server le-a manipulat. Chiar și pe servere care rulează pachetul Nginx defect, doar un subset de cereri a eșuat. Regresia a afectat reguli specifice de rutare nginx mai degrabă decât întreaga configurație proxy, atât de multe modele URL-ul a continuat să funcționeze în mod normal pe un server afectat. Incidentul a fost complet rezolvat prin 08:11 PDT după ce fiecare server afectat a fost actualizat la pachetul corectat și verificat sănătos. Nicio acțiune a clientului nu a fost sau este necesară. ## Ce a fost afectat Numerele de mai jos sunt doar eşecuri cauzate de acest incident. Raspunsurile obisnuite 404 au fost identificate prin semnatura lor distincta de raspuns si excluse. Da. Cum arăta asta în practică: * ** Integrari API** au primit HTTP 404 răspunsuri pentru cereri valabile. Deoarece eșecurile au fost imediate și apatrizi, retries client ar putea reuși atunci când au aterizat pe un server neafectat. * **Dashboard and login** pages nu a reușit să încarce sau să semneze intermitent. * Eșecurile depind de URL-ul exact: unele tipuri de cereri au trecut prin neafectat chiar și pe servere defecte, adăugând la aspectul intermitent. ## Ce nu a fost afectat * **In-cart cereri de rating.** Toate cererile de rating de la portalul web, platformele de e-commerce, platformele ERP și cererile regulate de API pentru * ** Locuri de muncă Background nu au fost afectate deloc.** Toate procesele asincrone - locuri de muncă programate, scrie pe spate, sincronizare inventar, livrare webhook, generarea de documente și etichete, transport și comunicații ERP - se execută în spatele stratului proxy și a continuat în mod normal pe parcursul incidentului. Nu s-a pierdut sau s-a amânat nici o muncă la coadă. * **Integritatea datelor.** Nu au fost pierdute, modificate sau corupte date. Cererile au fost completate în mod normal sau au fost respinse direct. * **Security and entance.** Nici o cerere nu a fost direcţionată către un alt cont şi nicio limită de securitate nu a fost depăşită. Corupția a avut loc după ce au fost aplicate toate controalele de acces. Actualizarea care stă la baza Ubuntu a fost un plasture preventiv de securitate; vulnerabilitatea pe care a abordat-o nu a fost exploatată pe sistemele noastre. Traducerea şi adaptarea: * ** Aug 19 \ (zi\) ** - Ubuntu publică o actualizare de securitate pentru nginx; un defect este raportat, iar Ubuntu publică un pachet corectat în aceeași zi. Versiunea corectată se propagă către oglinzile publice actualizate peste noapte. * ** Aug 19, 18:24 - 23:09** - Verificarea actualizării nocturne a serverelor afectate ulterior descărca actualizarea Nginx zi. În aceste momente, clădirea defectă este încă cea mai nouă disponibilă pe oglinzi. Acest pas descarcă doar pachetul; instalarea are loc în fereastra de petice a doua zi. * ** Aug 20, 04:12 - 05:05** - Un alt grup de servere ruleaza verificarea updatarii nocturne dupa ce constructia corectata a ajuns la oglinzi. Aceste servere descarcă versiunea fixă și rămân sănătoase pe tot parcursul incidentului. * ** ~ 06:00** - O actualizare de rutină, fără legătură cu configurarea aplicației este aplicată pentru viitoarele versiuni. Nu are niciun efect asupra funcţionalităţii eliberate în prezent şi ** nu joacă niciun rol în incident**, ci pentru că este singura schimbare cunoscută în acea dimineaţă, devine primul suspect odată ce apar erori. * **06:00** - Fereastra de peticire automată pe timp de noapte începe de rulare actualizări nginx în medii. Unele servere au deja pachetul corectat descărcat, în timp ce altele au pachetul defect. * **06:31 - 06:34 - INCIDENT START. ** Pe măsură ce fereastra automată de rulare patch progresează, pachetul Nginx descărcat anterior este instalat pe mai multe servere web și de conectare în medii de producție partajate. Deoarece programele de patch-uri sunt clatinate, nu toate serverele se actualizează simultan, iar unele servere rămân sănătoase. Primele cereri eșuate cu care se confruntă clienții încep la **06:31**. * **06:35** - Alerte automate de monitorizare externă privind erorile ridicate. ** Investigaţia începe imediat. ** * **06:36 - 07:15** - Inginerii investighează mai întâi actualizarea configurației ~06:00, singura modificare cunoscută a nivelului de aplicație cu sincronizarea strânsă. Este exclusă, iar atenţia se îndreaptă spre stratul web/proxy. * **06:52** - Fereastra de rulare continuă și pachetul defectuos este activat pe servere suplimentare. Impact crește pe măsură ce serverele mai afectate repornesc pe versiunea nginx defectă, în timp ce serverele care au descărcat pachetul corectat Ubuntu rămân sănătoase. * **06:55** - Un server web rămas actualizări folosind pachetul corectat Ubuntu și rămâne sănătos pe tot parcursul, continuând să servească cota sa de trafic corect. * **07:18 - 07:19** - Serverele web afectate sunt reluate ca o încercare de atenuare. Acest lucru nu are niciun efect deoarece pachetul Nginx defect rămâne instalat. * **07:20 - 07:55** - Serverele suspecte sunt eliminate din rotaţia balanţei de sarcină. Simptomele persistă deoarece mediile de conectare și de aplicare sunt afectate independent, ceea ce lărgește semnificativ căutarea. * **07:41** - Modelul URL-corupție este identificat în jurnalele de aplicații. * **07:45 - 08:00** - Testarea Per-server izolează serverele defecte. Singura diferență de la servere sănătoase este versiunea pachet nginx. Construcţia defectă se potriveşte cu anunţul de regresie publicat de Ubuntu şi pachetul corectat. * **08:02 - 08:11** - Pachetul corectat este instalat pe toate serverele afectate. Ratele de eroare revin la normal imediat pe fiecare server pe măsură ce reporneşte pe versiunea fixă. Ultimul mediu afectat revine la normal la **08:11 - INCIDENT FULLY RESOLVED**. * **08:11\+** - Verificarea completă este completă: fiecare server este testat individual, și API, bord, login, și medii de producție sunt confirmate sănătos. ## Why rezolution take ~95 minutes from alert Detectarea a fost rapidă, dar trei factori au încetinit diagnosticul. În primul rând, o schimbare de configurare de rutină mai devreme în acea dimineață a fost singura schimbare cunoscută în mediu și a trebuit să fie exclusă - patch-uri automate OS nu apare în orice jurnal de schimbare de nivel de aplicare. În al doilea rând, eșecul a fost intermitent prin natura sa: serverele neafectate au continuat să servească normal și chiar serverele afectate au manipulat cu succes tipurile de cereri ale căror reguli de rutare nu au fost afectate. În al treilea rând, eliminarea serverelor suspecte din rotație nu a oprit erorile - deoarece alte niveluri au fost afectate în mod independent - care au indicat inițial ancheta departe de aceste servere. ## What We are changing **1. Patch-uri de securitate ale sistemului de operare înainte de producție. ** Actualizări automate de securitate OS- și nginx, inclusiv patch-uri critice, vor fi instalate mai întâi pe servere neproductive. Validarea automată la nivel de aplicație va exercita API reprezentativ, bord, și căi de conectare împotriva serverelor actualizate înainte de aceleași versiuni de pachet sunt permise pentru a rula în producție. Prelungirea producţiei va începe numai după ce aceste controale vor trece. **2. Diagnosticare mai rapidă la nivel de versiune. ** Dosarele noastre de incidente includ acum compararea imediată a versiunilor de pachete și repornirea istoriei pe servere ori de câte ori serverele identice-configurate se comportă diferit.
Traducere automată din actualizarea oficială a incidentului.
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.
Resolved by FedEx
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
This incident has been resolved.
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.
Resolved by PrintNode.
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.
Resolved by FedEx.
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
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
The AWS issue affecting carriers has been resolved.
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
Resolved by USPS Endicia
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.
Confirmed as resolved by WWEX.
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.
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.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
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
This incident has been resolved.
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.
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.
This incident has been resolved.
Some customers are experiencing slowness with the rating API. Our team is actively investigating the issue. We will provide updates as we learn more.
The issue causing slowness in the rating API has been identified and resolved.
This incident has been resolved.
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
Resolved by Pitney Bowes
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
UPS resolved the issue on their side, we will continue to monitor it.
This incident has been resolved.
USPS Endicia has noted that they have fixed the postage printing issue. See USPS Endicia status page for more details: https://status.endicia.com/
Resolved by Endicia.
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
Resolved by FedEx.
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
Resolved by FedEx team.
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
Resolved by UPS.