55 Shiphawk incidents · 2021년 2월 — official updates, affected components, duration and resolution details.
FedEx 웹 서비스는 현재 등급의 성능을 경험하고 있으며 일부 고객이 FedEx 배송을 예약했다고보고했습니다. FedEx가 문제를 해결하기 위해 계속 상황을 모니터링 할 것입니다. 현재 FedEx 응답 시간은 다음과 같습니다. https://www.shippingapimonitor.com/history.html?api=fedex
FedEx 측에 해결.
공식 인시던트 업데이트를 자동 번역했습니다.
일부 고객은 WMS 액세스와 느린 경험. 우리의 팀은 적극적으로 문제를 조사하고 있습니다.
수정이 구현되어 결과를 모니터링하고 있습니다.
이 사건은 해결되었습니다. 우리는 그들이 가능한 한 빨리 세부 사항을 공유 할 것입니다.
## Post-Incident 보고서: 하나의 데이터베이스 인스턴스에 창고에 대한 WMS 슬픔과 오류 - 8 월 25, 2026 ** 서버:** 해결 된 **문의 창:** 8월 25, 2026, ~04:30 - 08:45 PDT \(07:30 - 11:45 ET\) ** 완료:** 데이터베이스가 미국 동부 창고 그룹에서 하나의 WMS 데이터베이스 인스턴스에서 호스팅되는 고객 : 최대 20x 정상의 페이지로드 시간, 스캐너 및 관리자 화면의 간헐적 오류 최악의 기간 동안. ** 영향을받지 않음: ** 다른 모든 WMS 데이터베이스 인스턴스 및 창고 그룹, TMS 플랫폼, 데이터 무결성 \ (거래 손실, 복제, 또는 부분적으로 적용되는 \) 및 모든 완료 작업 - 허용 된 모든 거래는 올바르게 처리되었습니다. # ## 당신은 영향을 줄 수 있습니까? 충격은 WMS 데이터베이스가 미국 동부 창고 그룹에서 하나의 특정 데이터베이스 인스턴스에 호스팅되는 고객에게 제한되었으며 8 월 25 일 아침에만 적용됩니다 (약 04:30 - 08:45 PDT / 07:30 - 11:45 ET). 해당 창에서 WMS의 느린 페이지로드가 보이지 않았다면 환경이 관련되지 않았습니다. 다른 모든 WMS 데이터베이스 인스턴스 및 창고 그룹, 및 전체 TMS 플랫폼, 일반적으로 전반 운영. ### 요약 8월 24일 저녁에는 ShipHawk 데이터를 데이터 창고에 복사하는 타사 ETL 서비스가 생산 데이터베이스 중 하나에 대해 한 번에 동기화 작업의 큰 배치를 다시 시작했습니다. 각 재시작 작업은 전체 속도, 병렬 및 제한없이 모든 속도에서 역사적인 변경 데이터의 백로를 다시 읽기 시작했다. 예상 피크를 약 5 배로 늘리고 데이터베이스 인스턴스에 사용할 수있는 디스크 대역폭의 대부분을 소비합니다. 이 밤새, 창고 활동이 빛 때, 그래서 시간에 가동에 아무 효력도 없었습니다. 미국 동부 아침 교대가 8월 25일에 시작될 때, 정상 WMS 활동은 이미 포화 수로의 정상에 추가되고 인스턴스는 대역폭 한계를 도달했습니다. 애플리케이션의 관점에서이 느린 데이터베이스 응답으로 등장했습니다. 일반적으로 밀리 초에 반환하는 쿼리는 훨씬 길어졌으며, 그 뒤에 할당 된 작업, 페이지가 천천히로드되었습니다. 데이터베이스 응답이 애플리케이션의 타임 아웃을 초과하는 경우, 페이지는 로딩 대신 오류를 반환합니다. 서비스는 전반적으로 운영됩니다. 영향을 받은 인스턴스를 가로지르는 고객은 그 창 \(picks, packs and 재고 moves\)에서 일반적으로 처리되는 볼륨의 약 70 %를 처리했지만 경험은 느리고 시간이 어렵고 고객 간의 영향을 미칩니다. ETL 서비스 데이터베이스 자격 증명을 08:37 PDT로 변경하여 해결된 상황. 데이터베이스는 8 분 이내에 복구됩니다. 지연된 일은 뒤에 오는 2 시간 이상를 통해서, 그리고 모든 영향 받은 창고는 정상적인 속도로 뒤이었습니다. 고객 행동이 필요하거나, 데이터가 영향을받지 않습니다. 거래가 분실, 복제, 또는 부분적으로 적용되지 않았습니다 - 우리는 전체 사건 창을 다루는 통합 로그에 대해 확인했습니다. 제대로 완료되었거나 변경하기 전에 깨끗하게 실패한 일. 아래에서 덮여 있습니다. ### 영향을받는 것 충격은 미국 동부 창고 그룹에서 영향을받는 WMS 데이터베이스 인스턴스에 호스팅되는 고객에게 제한되었습니다. 사건 창을 통해 시스템은 보드를 가로 질러 느꼈다 - 스캐너 및 관리자 페이지는 일반적으로 두 번째 밑에 잘로드하는 많은 시간을 더 길게했다 - 그리고 데이터베이스 응답이 애플리케이션 타임 아웃을 초과하는 경우, 페이지는로드보다 오류를 반환. 이 연습과 같은 것 : **웨어하우스 바닥:** 스캐너 페이지 \(picking, moving, Adjusting 재고 표시) 매우 천천히로드; 페이지가 붙어있는 동안 검색 한 작업자는 오류 페이지를 수신하고 다시 이동하고 조치를 반복 할 수 있었다. **이러한 파열에 집중되어 있기 때문에 파열이 발생했습니다.** 그 중 대부분은 혼잡의 피크에서 15 분 창 안에 떨어졌다 \(06:15 - 06:30 PDT\). 웹 서버 및 응용 프로그램 로그에서 확인 된 오류 페이지를 계산, 가장 영향을받는 창고는 그 창에서 71을 보았다. **시스템은 계속 유지됩니다.** 모든 제출 된 거래는 제대로 완료하거나 변경하기 전에 깨끗하게 실패합니다. 가장 깊은 느리게 창 도중 우리는 계속 일하는 사용자를 위해 성공적으로 완료하는 수백의 거래를 보여줄 수 있습니다. ### 영향을받지 못했습니다. ** 데이터 무결성. ** 오류는 요청 처리의 시작 부분에 발생했습니다. 변경 전에. 거래가 분실, 복제, 또는 부분적으로 적용되지 않았습니다. 모든 이행, 재고 이동, 그리고 완료된 선적은 이렇게 정확하게 했습니다 - 우리는 사건 창을 위한 통합 통나무를 확인했습니다. ** ERP 및 마켓 플레이스에 대한 주문 및 배송 동기화 **가 올바르게 완료되었습니다. 느리게 동안 누락 된 게시물은 캐치 업 \ 동안 전체로 전달되었습니다 (통합 로그에서 검증 됨 - 실패한 게시물 없음). ** 다른 모든 환경. ** 다른 데이터베이스 인스턴스에 창고, 전체 TMS 플랫폼, 일반적으로 운영. **보안 및 공시.** 보안 경계는 어떤 시점에 포함되지 않았습니다. 질문의 제 3 자 서비스는 우리가 발행 한 자격의 밑에 운영되는 자료 통합 납품업자입니다; 문제는 그것의 읽음의 양이었습니다, 어떤 허가한 접근. ### 타임라인 \(모든 시간 PDT; ET\ 3시간 추가) | 이벤트 | 인포메이션 | 8월 24일, 22:54 - 22:57 | ETL 서비스 시작 ~22 분 창 내에서 데이터베이스에 대한 동기화 작업. 전체 속도로 과거의 변화 데이터를 재개합니다. | | 8월 24일, 22:54 - 23:50 | 예상치 못한 피크를 대략 5배 읽는 볼륨, 인스턴스에 사용할 수있는 디스크 대역폭의 대부분을 소모. 하룻밤의 창고 교통이 빛이므로 고객 부담이 없습니다. | | 8월 25일～04:30 | 미국 동부 창고 아침 교대 시작 결합된 수요는 capped 네트워크 속도를 초과합니다; 큐는 건물을 시작하고 첫번째 페이지는 정상적인 보다는 더 느립니다. | | 05:30 | 자동 응답 시간 모니터링 알림 창고 활동 램프 업; 슬픔의 고객 보고서는 같은 기간에 도착합니다. 투자 개시 | | 06:00 - 07:00 | 피크 혼잡: 데이터베이스 연결 스파이크 ~ 15x 정상 요청 더미 업; 스캐너 화면 오류의 파는 \(06:15-06:30\). · | 06:50 | 루트 식별 : 인스턴스 제한을 통한 디스크 대역폭; 드라이버로 식별 된 공급 업체의 복제 스트림. | | 07:00 | 하비스타 내부 보고서 쿼리 무료 용량 - 부분 릴리프. | | 07:20 - 08:30 | ETL 서비스 동기화 작업은 콘솔 및 데이터베이스 세션에서 일시 중지됩니다. 각 시간 내에 자동으로 다시 연결되며 계속 읽기. 이 기간 동안 추가 작업을 시작합니다. · | 08:35 | ETL 서비스 데이터베이스 자격은 잠겨 있으며 그 세션은 최종 시간을 종료했습니다. | | 08:38 - 08:45 | 데이터베이스 큐 드레인; 페이지 응답 시간은 정상으로 돌아갑니다. 고객 영향 종료. | ## 왜 해결책이 첫번째 보고에서 3 시간 걸렸습니다 3개의 요인은 타임라인을 확장했습니다. 첫째, 트리거는 증상의 7 시간 전에 발생했습니다. ETL 서비스 리레드 랜 하룻밤에 이미 사용 가능한 대역폭을 소비했지만, 그 시간에 창고 활동 빛은 시스템 응답 시간에 약간의 변화를 생산 - 우리의 경고 임계값 아래 - 그래서 발견되지 않았습니다. 우리의 자동화된 감시는 일단 창고 활동이 아침에 올린 때 경고를 했습니다, 그러나 그 때의 밑에 변화는 7 시간 오래 이고 점에 최근 배치 또는 윤곽 변화가 없었습니다. 두 번째, ETL 서비스의 복제는 표준 데이터베이스 쿼리 로그에 보이지 않는 - 그들은 쿼리보다 복제 프로토콜을 사용한다 - 그래서 소비자가 디스크, 네트워크 및 연결 수준 증거를 상관 관계로 식별. 세 번째, ETL 서비스는 중단을 생존하기 위해 내장되어 있습니다. 작업과 연결이 초당 자동으로 연결되므로 완화로 실패하고 다른 사람들을 포장하면서 추가 작업을 다시 시작합니다. 자격 증명만 수정했습니다. ## # 우리가 변화하는 것 ** WMS 응답 시간 경고 임계 값. ** 이 사건 뒤에 조건은 하룻밤 7 시간 동안 선물되었습니다, 그러나 빛 짐의 밑에 그것은 우리의 경고 문턱을 교차하기 위하여 응답 시간을 너무 작게 움직였습니다 - 그래서 첫번째 경고는 단지 한 번 창고 활동 경사지고 고객은 이미 영향을 줬습니다. 우리는 낮은 부하를 포함하여 WMS 응답 시간에 있는 더 작은 교대에 과민한 그 문턱을 튜닝하고, 이렇게 사건은 그들이 고객을 도달하기 전에 붙잡고 행동합니다. 이 사건의 특정 주요 지표에 경고를 포함 - 디스크 대역폭 소비 및 디스크 큐 깊이. ** 데이터베이스는 실질적으로 더 많은 디스크 대역폭이있는 인스턴스 유형으로 마이그레이션되었습니다 **, 이 종류의 스파이크를 흡수하기 위해 피크 수요의 중요한 헤드룸을 제공합니다. ** ETL 공급 업체와 함께 우리의 조사를 계속하고 있습니다. ** 우리는 동시 작업 재시작에 대한 설명을 찾고있는 개방적인 케이스를 가지고 있으며, 고객 소스에 대한 재읽을 수있는 제한 및 통화 캡을 필요로합니다. 그것은 계속됩니다.
공식 인시던트 업데이트를 자동 번역했습니다.
TMS WebPortal이 오류를 반환하거나 일부 고객에게로드하지 못하는 보고서를 받았습니다. 우리는 적극적으로 문제가 투자하고 더 많은 정보를 제공 할 것입니다.
문제는 식별되고 수정이 구현됩니다.
수정이 구현되어 결과를 모니터링하고 있습니다.
이 사건은 해결되었습니다.
# Post-Incident 보고서 : API 및 로그인 오류 - 8 월 20, 2026 ** 서버:** 해결 된 **문의 창:** 8월 20, 2026, 06:31 - 08:11 PDT \(13:31 - 15:11 UTC\) **Affected: ** ShipHawk API 및 대시보드 요청은 공유된 생산 환경, 그리고 로그인 서비스. 충격은 완전한 정전 보다는 오히려 부분이었습니다: [shiphawk.com] (http://shiphawk.com)에 전반적인 API 교통의 대략 25%는 그것의 영향 받은 창 도중 실패했습니다; 영향 받은 환경 내의 고장율은 대략 37%에서 48%에 배열되고, 로그인 서비스 요구의 대략 41%는 실패했습니다. ** 영향을받지 않음:** In-Cart 등급 \(모든 /api/v4/rates request\), 백그라운드 처리 \(모든 예약된 작업, 백 작성, webhooks, async 라벨 생성, 추적 및 캐리어 통신 랜 일반적으로 \), 데이터 무결성. ## 요약 8 월 20 일 아침, Ubuntu에 게시 된 운영 체제의 중요한 보안 업데이트 - 우리의 표준 패치 프로세스에 의해 자동으로 적용 - ShipHawk 응용 프로그램의 앞에 앉아있는 웹 서버 구성 요소 \ (nginx \)의 결함이 포함. 영향을받은 패키지는 8 월 19 일에 [USN-8563-3](https://ubuntu.com/security/notices/USN-8563-3)로 출판되었습니다. 우분투는이 업데이트가 회귀를 도입하고 게시 된 것을 확인 [USN-8563-4](https://ubuntu.com/security/notices/USN-8563-4) 같은 날, 더 조사를 종료 문제 변화. 잘못된 버전이 실행되었지만, 프록시 레이어는 응용 프로그램에 손을 잡고하기 전에 많은 들어오는 요청의 URL을 손상했습니다. 이 응용 프로그램은 알려진 엔드 포인트에 손상된 URL과 응답 할 수 없습니다 ** 404 찾을 수 없습니다 **. 실패는 즉시, 청결한 거절이었습니다: 아무 요구도 부분적으로 가공되지 않았습니다, 잘못된 계정에 경로를, 또는 합격 후에 잃었습니다. 우리의 서버는 모든 다운로드가 아니며 동시에 운영 체제 보안 업데이트를 설치하지 않습니다. 업데이트 체크 및 설치 창은 호스트 전역에 비틀어 있습니다. 결과적으로 일부 서버는 Ubuntu가 올바른 패키지를 게시하기 전에 잘못된 nginx 빌드를 다운로드했지만 나중에 수정 된 빌드를 직접 다운로드했습니다. 이미 잘못된 패키지를 다운로드 한 서버는 예정된 설치 ran 때 영향을 받았습니다. 이것은 문제가 간헐적 인 것으로 나타났습니다. 그렇지 않으면 필수 요청이 실패하거나 그 서버에 따라 성공할 수 있습니다. 잘못된 nginx 패키지를 실행하는 서버에서도 요청의 하위 설정만 실패했습니다. 회귀는 특정 nginx routing 규칙을 전체 프록시 구성보다 오히려 영향을받는 서버에서 일반적으로 작동하도록 많은 URL 패턴을 영향을 미쳤습니다. 사건은 08:11 PDT에 의해 완전히 해결되었습니다. 영향을받은 서버가 올바른 패키지로 업그레이드되었으며 건강하게 확인되었습니다. 고객 활동이 없거나 요구됩니다. ## 영향을받는 것 아래 숫자 **이 사건에 의한 실패 **. 정규 404 응답 \ (실제로 존재하지 않는 레코드의 전망, 잘못된 URL, 봇 트래픽 \)는 특정 응답 서명 및 제외에 의해 식별되었습니다. | 환경 | 범위 | 충격 윈도우 \(PDT\) | 실패 요청 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sh-p-1 환경 | 3개의 웹 서버 | 06:34 - 08:08 | ≈37%의 대응 서버; ≈25%의 전반적인 API 트래픽 | | 로그인 서비스 | 두 서버 | 06:33 - 08:08 | 로그인 서비스 요청의 ≈41% | sh-p-2 환경 | 2 의 3 웹 서버 | 06:31 - 08:08 | ≈47% 의 요청에 영향을 주는 서버 | | sh-p-3 환경 | 2 의 3 웹 서버 | 06:31 - 08:11 | ≈48% 의 요청에 영향을 주는 서버 | 이 연습과 같은 것 : * **API 통합 ** 유효한 요청에 대한 HTTP 404 응답을 받았습니다. 실패가 즉각적인 상태이므로 클라이언트는 비범죄 서버에 착륙했을 때 성공할 수 있습니다. * **Dashboard 및 로그인 ** 페이지는 Intermittently에 로드하거나 서명하지 못했습니다. * 실패는 정확한 URL에 달려 있습니다: 몇몇 요구 유형은 결함이 서버에서 조차, intermittent 외관에 추가하. ## 영향을받지 못했습니다. * **차량 등급 요청.** 웹 포털, 전자 상거래 플랫폼, ERP 플랫폼 및 일반 API 요청에서 모든 등급 요청은 "/api/v4/rates"가 평소처럼 작동했습니다. * ** 배경 작업은 전혀 영향을받지 않았습니다. ** 모든 비동기 처리 - 예약 된 작업, 백업, 재고 동기화, 웹훅 배달, 문서 및 라벨 생성, 캐리어 및 ERP 통신 - 프록시 층 뒤에 실행하고 일반적으로 사건 전체에 걸쳐 계속. 누락된 작품은 분실 또는 지연되지 않았습니다. * ** 데이터 무결성.** 데이터가 분실, 변경 또는 손상되지 않았습니다. 자주 묻는 질문 * **보안 및 공시.** 요청이 다른 계정에 경로를 밟고 보안 경계가 교차되지 않았습니다. 모든 액세스 제어가 적용 된 후 손상이 발생했습니다. Ubuntu 업데이트가 예방 보안 패치였습니다. 취약점은 시스템에 접근되지 않았습니다. ## 타임라인 \(모든 시간 PDT, 8월 20, 2026\) * **Aug 19 \(daytime\)** - Ubuntu는 nginx의 보안 업데이트를 게시합니다. 결함이 보고되고 Ubuntu는 올바른 패키지를 당일 발행합니다. 올바른 버전은 밤새 공개 업데이트 거울에 전파합니다. * **Aug 19, 18:24 - 23:09** - 늦은 서버에서 야간 업데이트 체크는 하루의 nginx 업데이트를 다운로드합니다. 이 순간에, 결함 구조는 여전히 거울에 사용할 수 있습니다. 이 단계는 패키지를 다운로드합니다; 설치는 다음 아침 패치 창 동안 발생합니다. * **Aug 20, 04:12 - 05:05** - 서버의 또 다른 그룹은 정확한 빌드가 거울에 도달 한 후 야간 업데이트 체크를 실행합니다. 이 서버는 고정 버전을 다운로드하고 사건 전체에 건강 유지. * **~06:00** - 일상, 관련 응용 프로그램 구성 업데이트가 다가오는 릴리스에 적용됩니다. 현재 출시된 기능에 영향을 미쳤습니다. **이 사건에 아무런 역할을 하지 않습니다.**, 하지만 그것은 단지 알려진 변경 때문에 아침, 그것은 첫 번째 의심의 여지가되면 오류가 나타납니다. * **06:00** - 야간 자동 패치 창은 환경 전반에 걸쳐 nginx 업데이트를 롤링 시작합니다. 일부 서버는 이미 올바른 패키지를 가지고, 다른 사람들은 잘못된 패키지를 가지고. * ** 06:31 - 06:34 - 기본 시작. ** 롤링 자동화 패치 창 진행으로 이전에 다운로드된 오류 nginx 패키지는 공유된 생산 환경에서 여러 웹 및 로그인 서버에 설치됩니다. 패치 일정이 비틀기 때문에 모든 서버가 한 번에 업데이트되지 않으며 일부 서버는 건강하게 유지됩니다. 첫 번째 고객 회의 실패 요청은 ** 06:31**에서 시작됩니다. * **06:35** - 높은 오류에 자동 외부 모니터링 경고. **투자가 즉시 시작됩니다.** * **06:36 - 07:15** - 엔지니어는 먼저 ~06:00 구성 업데이트, 밀접한 일치 타이밍과 유일한 알려진 응용 수준 변경을 조사합니다. 그것은 규칙화되고, 주의는 web/proxy 층으로 돌립니다. * **06:52** - 롤링 패치 창이 계속되고 결함 패키지는 추가 서버에서 활성화됩니다. 영향을받는 서버가 오류 nginx 버전으로 다시 시작되므로 Ubuntu의 올바른 패키지를 다운로드 한 서버가 건강하게 유지됩니다. * **06:55** - Ubuntu의 올바른 패키지를 사용하여 남아있는 웹 서버 업데이트가 건강하게 유지되며 트래픽을 올바르게 공유 할 수 있습니다. * **07:18 - 07:19** - 웹 서버가 완화 시도로 재시작됩니다. 이 오류 nginx 패키지가 설치되기 때문에 효과가 없습니다. * **07:20 - 07:55** - 서버가 로드밸런서 회전에서 제거됩니다. 로그인 서비스 및 응용 환경이 독립적으로 영향을 미치기 때문에 증상 persist. * **07:41** - URL-corruption 패턴은 애플리케이션 로그에서 식별됩니다. * **07:45 - 08:00** - Per-server 테스트는 잘못된 서버입니다. 건강한 서버의 유일한 차이점은 nginx 패키지 버전입니다. 잘못된 빌드는 Ubuntu의 게시 회귀 통지 및 수정 된 패키지와 일치합니다. * **08:02 - 08:11** - 모든 영향 서버에서 올바른 패키지가 설치됩니다. 오류율은 각 서버에 즉시 반환하여 고정 버전으로 다시 시작합니다. 최종 영향을 받은 환경은 **08:11에서 정상으로 돌아갑니다. * **08:11\+** - 전체 검증 완료: 모든 서버는 개별적으로 테스트, API, 대쉬보드, 로그인 및 생산 환경이 건강하게 확인됩니다. ## 왜 해결책이 ~95 분 경고에서 가지고 갔습니다 탐지는 빠르고, 그러나 3개의 요인 느린 진단이었습니다. 첫째, 일상적인 구성은 아침이 환경의 유일한 알려진 변경이었기 때문에 규칙이있었습니다. - 자동화 된 OS 패치는 모든 애플리케이션 레벨 변경 로그에 표시되지 않습니다. 두 번째, 실패는 자연에 의해 간헐적이었다: unaffected 서버는 일반적으로 서빙을 계속, 심지어 영향을받는 서버 성공적으로 처리 요청 유형 누가 영향을 미치지 않았다. 셋째, 교체에서 의심스러운 서버를 제거하지 않은 오류를 멈추지 않았다 - 다른 계층이 독립적으로 영향을 받지 않았기 때문에 - 그 서버에서 조사를 처음 지적했다. ## 우리가 변화하는 것 **1. 생산 전 단계 운영 시스템 보안 패치.** 자동화된 OS-와 nginx-level 보안 업데이트, 중요한 패치를 포함 하 여, 첫 번째 비 생산 서버에 설치 됩니다. 자동화된 애플리케이션 레벨 검증은 동일한 패키지 버전의 업데이트된 서버에 대한 대표 API, 대시보드 및 로그인 경로가 생산에 롤할 수 있도록 허용됩니다. 생산 롤아웃은 그 체크 패스 후에만 시작됩니다. **2. 더 빠른 버전 레벨 진단.** 우리의 사건 runbooks는 이제 패키지 버전의 즉각적인 비교와 동일한 구성 서버가 다르게 동작할 때마다 서버 전역의 재시작 기록을 포함합니다.
공식 인시던트 업데이트를 자동 번역했습니다.
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.
