55 Shiphawk incidents · 2021年2月 — official updates, affected components, duration and resolution details.
FedEx の Web サービスは現在、劣化したパフォーマンスを経験しており、一部の顧客は FedEx の出荷を予約する問題を報告しています。 FedEx は、問題の解決に取り組みながら、引き続き状況を監視します。 現在の FedEx 応答時間はこちら: https://www.shippingapimonitor.com/history.html?api=fedex
FedEx 側で解決.
公式のインシデント更新を自動翻訳しています。
一部の顧客はWMSアクセスで遅くなっています。 私たちのチームは積極的に問題を調査しています.
修正を実装し、結果を監視しています.
この事件は解決しました。 詳細については、できるだけ早く共有します.
## Post-Incident Report: WMS の1つのデータベースインスタンスの倉庫の損失とエラー - 8月 25, 2026 **ステータス:** 解決する **窓:** 8月25日、2026日 ~04:30 - 08:45 PDT \(07:30 - 11:45 ET\) **影響される:** 米国東倉庫グループでは、データベースが1つのWMSデータベースインスタンスでホストされているお客様:最大20xのページの読み込み時間、最悪の期間にスキャナと管理者画面の断続的なエラー。 **影響を受けない:** 他のWMSデータベースインスタンスと倉庫グループ、TMSプラットフォーム、データ整合性\(トランザクションの紛失、複製、または部分的に適用される\)、および完了したすべての作業 - 受け入れられたすべてのトランザクションが正しく処理された。 ### 影響を受けるか? 米国東倉庫グループでは、WMSデータベースが1つの特定のデータベースインスタンスでホストされているお客様に限り、8月25日午前中にのみ影響が認められました。(約4:30〜8:30 PDT / 07:30〜11:45 ET\) そのウィンドウの間にWMSに遅いページが読み込まれていない場合は、環境は関与していませんでした。 他のWMSデータベースインスタンスと倉庫グループ、およびTMSプラットフォーム全体が正常に動作しています。 #### 概要 8月24日の夕方、ShipHawkデータを当社のデータウェアハウスにコピーするサードパーティのETLサービスは、生産データベースの1つに対して一度に同期ジョブの大きなバッチを再起動しました。 再起動されたジョブは、全速度で履歴変更データのバックログを再読み込みし、並行して任意の速度制限なしで開始しました。 期待するピークが約5倍に上昇したボリュームを読み、そのデータベースインスタンスに利用可能なディスク帯域幅の大部分を消費しました。 倉庫活動が軽くなったら一晩に始まったので、当時は作業に影響を与えなかった。 US-East 朝のシフトが 8 月 25 日に開始されたとき、すでに飽和したチャネルの上に通常の WMS アクティビティが追加され、インスタンスは帯域幅制限に達しました。 アプリケーションの観点から、これは遅いデータベースの応答として登場しました: 通常、ミリ秒で戻ってくるクエリは、作業は、それらを後ろにキューに入れ、ゆっくりと読み込まれました。 データベースの応答がアプリケーションのタイムアウトを超えた場合、ページは読み込みの代わりにエラーを返します。 本サービスは、本サービスの運営を継続します。 影響を受けたインスタンス全体で、通常、そのウィンドウ\(ピック、パック、在庫の移動\)で処理されるボリュームの約70%を処理した顧客は、経験が遅く、作業が困難であったり、顧客との間の影響の程度が変化しました。 状況は、ETLサービスデータベースの資格情報を完全に0837 PDTに置き換えることによって解決しました。 データベースは8分以内に回復しました。 下記の2時間以上経過した作業を遅延させ、影響を受けた倉庫は通常のペースに戻りました。 顧客行動が要求されず、データが影響されませんでした。 トランザクションが失われたり、重複したり、部分的に適用されなかったり - 完全なインシデントウィンドウをカバーする統合ログに対してこれを検証しました。 変更を加える前に、正しく提出されたか、きれいに失敗したかのどちらかの作業。 詳細はこちらをご覧ください。 ### 影響を受けたこと 影響は、米国東倉庫グループにおける影響を受けるWMSデータベースインスタンスでデータベースがホストされているお客様に限ります。 インシデントウィンドウを通して、システムがボード全体に遅くなっていた - スキャナーと管理者ページが秒単位でよく読み込まれたページは、何度も時間がかかり、データベース応答がアプリケーションのタイムアウトを上回ったところ、ページはロードではなくエラーを返します。 これは練習のように見えるもの: **倉庫フロア:**スキャナーページ\(ピック、移動、在庫調整)が非常にゆっくりと読み込まれています。ページが立ち往生しているワーカーは、エラーページを受信し、アクションを繰り返す可能性があります。 **事故は、事件を越えるのではなく、単一のバーストに集中していた。** それらのほとんどは、混雑のピークで1 15分ウィンドウ以内に落ちました\(06:15 - 06:30 PDT\)。 ウェブサーバーおよびアプリケーションログで確認されたエラーページをカウントすると、そのウィンドウで最も影響を受けた倉庫が71件見つかりました。 ※システム全体に残ります。** 提出されたすべてのトランザクションは、変更を加える前に、正しく完了するか、きれいに失敗するかのいずれかです。 最深のスローダウンウィンドウでは、作業を続けたユーザーが正常に完了するトランザクションの数百を表示することができます。 ### 影響を受けなかったこと **データの完全性。** 変更が行われた前に、処理の開始時にエラーが発生しました。 トランザクションが失われたり、重複したり、部分的に適用されていない。 完了したすべてのフルフィルメント、在庫の移動、および出荷の投稿が正しく行われた - インシデントウィンドウの統合ログを検証しました。 **ERPとマーケットプレイスへの注文と出荷同期**が正しく完了します。遅延時にキューに入れた投稿は、キャッチアップ\(統合ログで検証 - 失敗した投稿なし)中に配信されます。 ※その他全ての環境 他のデータベースインスタンスに倉庫を保管し、TMSプラットフォーム全体が正常に動作しています。 **セキュリティとテナント。** いかなる点でもセキュリティ境界は関与していません。 質問のサードパーティサービスは、私たちが発行した資格情報の下で動作するデータ統合ベンダーです。 問題は、その読み込みの量でした。 ## タイムライン \(全回PDT;ET\の3時間を追加) | イベント | イベント | | お問い合わせ | | 8月24日、22:54 - 22:57 | ETLサービスが3分間のウィンドウ内でデータベースとジョブを同期する ~22 を再起動します。 履歴変更データをフルスピードで読み直し開始 | | 8月24日、22:54 - 23:50 | 予想されるピークの約5倍に、ほとんどのディスク帯域幅をインスタンスに消費します。 深夜倉庫の交通が光るので、まだお客様目に見えない効果はありません | | 8月25日～04:30 | アメリカ東倉庫朝のシフトが始まります。 結合されたデマンドは、キャプチャされたネットワーク速度を上回ります。 キューはビルドを開始し、最初のページは通常のよりも遅くレンダリングを開始します。 | | 05:30 | 倉庫活動が遅れるにつれて自動応答時間監視アラートを自動で監視し、顧客レポートが同じ期間に到着します。 調査開始 | | 06:00 - 07:00 | ピーク混雑: データベース接続は〜15倍の通常のリクエストが重なるため、スキャナ画面のエラーの波は\(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 がエラーを返したり、一部の顧客に負荷をかけないという報告をいただきました。 問題を積極的に調査し、より多くの情報が利用可能になるようにアップデートを提供します.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
# 投稿事件報告:関連するAPIとログインエラー - 8月 20, 2026 **ステータス:** 解決する **事件窓:** 8月 20, 2026, 06:31 - 08:11 PDT \(13:31 - 15:11 UTC \) **影響:** ShipHawk API および共有生産環境のダッシュボード要求、およびログインサービス。 [shiphawk.com](http://shiphawk.com)の全体的な API トラフィックの約 25% が影響を受けたウィンドウに失敗しました。影響を受ける環境内の障害率はおよそ 37% から 48% の範囲で、約 41% のログインサービスリクエストが失敗しました。 **影響を受けない:** In-Cartの評価\(およびすべての/api/v4/ratesリクエスト\)、背景処理\(すべてのスケジュールされたジョブ、書き込みバック、Webhook、非同期ラベル生成、トラッキング、キャリア通信が正常に実行)、データの完全性。 ## 概要 8月20日の朝、Ubuntuが発行するオペレーティングシステムの重要なセキュリティ更新 - および標準パッチプロセスによって自動的に適用されます - ShipHawkアプリケーションの前に座っているWebサーバーコンポーネント\(nginx\)に欠陥が含まれています。 [USN-8563-3](https://ubuntu.com/security/notices/USN-8563-3) として8月19日に影響を受けるパッケージが公開されました。 Ubuntuは、この更新が再帰を導入し、公表したことを確認しました [USN-8563-4](https://ubuntu.com/security/notices/USN-8563-4) 同じ日に、問題のある変更をさらに調査に戻す。 障害のあるバージョンが実行されている間、プロキシレイヤーは、アプリケーションにそれらを渡す前に、多くの着信リクエストのURLを破損させました。 このアプリケーションは、既知のエンドポイントに破損したURLと回答できません**404 Not Found**。 障害は即時に、拒否をクリーンに: 要求は部分的に処理されなかったり、間違ったアカウントにルーティングしたり、受諾後に失った。 当社のサーバーは、オペレーティングシステムのセキュリティ更新を同時にダウンロードしてインストールしません。 更新チェックとインストールウィンドウは、ホスト全体に驚異的です。 その結果、一部のサーバーは、Ubuntuが修正されたパッケージを公開する前に、障害のあるnginxビルドをダウンロードしましたが、他のサーバーは後で確認し、修正されたビルドを直接ダウンロードしました。 既にダウンロードしたサーバーのみが、そのスケジュールされたインストールが実行されたときに不良パッケージが影響されました。 これは、問題が断続的に現れた理由です。そうしないと、そのサーバーが処理したサーバーに応じて、非代表的なリクエストが失敗したり成功したりする可能性があります。 障害のあるnginxパッケージを実行しているサーバーでも、リクエストのサブセットのみが失敗しました。 回帰は、プロキシ構成全体ではなく、特定のnginxルーティングルールに影響したため、多くのURLパターンが影響を受けたサーバーで正常に動作し続けています。 すべての影響を受けたサーバーが正しいパッケージに改善され、健康な確認された後、インシデントは 08:11 PDT によって十分に解決されました。 顧客行動は必須ではありません。 ## 影響を受けたこと 下記の数字は、このインシデントによる失敗のみ**です。 通常の404応答 \(本物的に存在しないレコードの見栄え、無効なURL、ボットトラフィック\)は、その異なる応答署名によって識別され、除外されました。 | 環境 | スコープ | 影響力のあるウィンドウ | 障害のあるリクエスト | | お問い合わせ | | sh-p-1 環境 | 2 の 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 と login** ページは、間接的にロードまたは署名に失敗しました。 * 障害は、正確な URL に依存します。一部のリクエストタイプは、障害のあるサーバーでも影響を受け、断続的な外観に追加します。 ## 影響を受けなかったこと * カート内での評価リクエスト ウェブポータル、電子商取引プラットフォーム、ERPプラットフォーム、通常のAPIリクエストから `/api/v4/rates` へのすべての評価リクエストは、通常どおり動作します。 *** バックグラウンドジョブは全く影響しません。** すべての非同期処理 - スケジュールされたジョブ、書き込みバック、在庫同期、Webhookの送達、文書およびラベル生成、キャリアおよびERP通信 - プロキシレイヤーの後ろで実行し、インシデント全体で正常に継続します。 キュートな作業が失われたり、遅れたりしませんでした。 ***データの完全性。** データの紛失、変更、破損は行いません。 普通に完了するか、または直立拒否されたかを要求します。 * **セキュリティとテナント。** 別のアカウントにリクエストを行わず、セキュリティ境界が交差しませんでした。 すべてのアクセス制御を適用した後、破損が発生しました。 Ubuntu のアップデートは、予防的なセキュリティパッチでした。 アドレスの脆弱性は、当社のシステムに悪用されていませんでした。 ## タイムライン \(全回PDT、8月20、2026\) ***Aug 19 \(日中\)** - Ubuntuはnginxのセキュリティ更新を公開します。不具合が報告され、Ubuntuは同じ日に修正されたパッケージを公開します。 修正されたバージョンは、公開更新ミラーを一晩に伝播します。 * **8月19日、18:24 - 23:09** - 夜間更新チェックは、日のnginx更新をダウンロードします。 これらの瞬間では、欠陥のあるビルドは、まだ鏡上で利用可能な最新です。 このステップはパッケージをダウンロードします。次の朝のパッチウィンドウの間にインストールが行われます。 ***Aug 20, 04:12 - 05:05** - サーバーの別のグループは、修正されたビルドがミラーに達した後、夜間更新チェックを実行します。 これらのサーバーは、固定版をダウンロードし、事件全体で健康を維持します。 ***~06:00** - ルーチン、関連のないアプリケーション構成の更新は、今後のリリースに適用されます。 現在リリースされた機能に影響を与えず、**インシデントでロールを再生しません。しかし、朝の唯一の既知の変化なので、エラーが現れたら最初の疑いになります。 ***06:00** - 夜間自動パッチングウィンドウは、環境全体でnginxの更新が始まります。 一部のサーバーには、すでに修正されたパッケージがダウンロードされていますが、他のサーバーには欠陥のあるパッケージがあります。 *06:31 - 06:34 - エントランススタート** ロール自動パッチウィンドウが進行するにつれて、以前にダウンロードした障害物nginxパッケージは、複数のWebおよび共有された生産環境にわたってログインサーバーにインストールされます。 パッチのスケジュールは、一度にすべてのサーバーの更新ではなく、一部のサーバーは健全です。 初めての顧客対応に失敗したリクエストは、**06:31**から始まります。 ***06:35** - 高められた間違いの外的な監視警報を自動化しました。 **調査はすぐに始まります。** *****06:36 - 07:15** - エンジニアは最初に~06:00構成の更新を調査します、近い一致のタイミングの唯一の知られた適用レベルの変更。 ウェブ/プロキシレイヤーに注目が向けられています。 ***06:52** - ローリングパッチウィンドウが続行し、障害のあるパッケージは、追加のサーバー上で活性化されます。 影響力のあるサーバーが故障したnginxバージョンに再起動すると、Ubuntuの修正されたパッケージをダウンロードしたサーバーは健康状態です。 ***06:55** - Ubuntuの修正されたパッケージを使用して残りのWebサーバーの更新を行い、全体的に健康を維持し、トラフィックの共有を正しく提供し続ける。 ***07:18 - 07:19** - 感染したWebサーバーは、緩和試みとして再起動されます。 故障したnginxのパッケージが取付けられているのでこれに効果がありません。 ***07:20〜 07:55** - ロードバランサーの回転からサスペクトサーバが削除されます。 ログインサービスとアプリケーション環境が独立して影響されるため、症状は持続します。これにより、検索が広くなります。 ***07:41** - URL-corruption パターンはアプリケーションログで識別されます。 ***07:45 - 08:00** - サーバテストは、障害のあるサーバーを分離します。 健康なサーバーとの唯一の違いは、nginxパッケージバージョンです。 障害のあるビルドは、Ubuntuの公開回帰通知と修正されたパッケージと一致しています。 ***08:02 - 08:11** - すべての影響を受けたサーバーに正しいパッケージがインストールされます。 エラーレートは、各サーバーの直近に戻って、固定バージョンに再起動します。 最終的な影響を受けた環境は、**08:11 - 完全に完全に解決**で正常に戻ります。 ***08:11\+** - 完全な検証が完了します。すべてのサーバーは個別にテストされ、API、ダッシュボード、ログイン、および生産環境は健康確認されます。 ## なぜ解像度が警告から〜95分を取ったのか 検出は高速でしたが、3つの要因は診断を遅くしました。 まず、朝が唯一の既知の環境の変化だったことの初期のルーチン構成が変更され、除外されなければならない - 自動化されたOSパッチは、任意のアプリケーションレベルの変更ログには表示されません。 第二に、障害は自然に断続的だった: 予期しないサーバーは、正常に機能し続け、さらに、影響を受けたサーバーは、規則が影響されていないタイプの要求を正常に処理しました。 第三に、回転から疑わしいサーバーを削除してもエラーを止めなかった - 他の層が独立して影響を受けたため - 当初はそれらのサーバーから調査を指摘した。 ## 何が変化しているのか **1. 生産前の段階のオペレーティング システムの保証パッチ。** 重要なパッチを含む自動OSおよびnginxレベルのセキュリティ更新は、最初に非生産サーバーにインストールされます。 自動化されたアプリケーションレベルのバリデーションは、同じパッケージバージョンが生産にロールする許可される前に、更新されたサーバーに対する代表的なAPI、ダッシュボード、およびログインパスを行使します。 生産ロールアウトは、そのチェックパスの後にのみ始まります。 **2. より速いバージョンレベルの診断。** 弊社のインシデント・ランブックには、パッケージ・バージョンの即時比較や、サーバー間での履歴を再起動するなど、同一構成のサーバーが動作するたびに異なります.
公式のインシデント更新を自動翻訳しています。
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.
