Historique des pannes de Shiphawk

1. 2 septembre 2026 à 16:24 UTCmonitoring

   Les services Web FedEx connaissent actuellement des performances dégradées, et certains clients ont signalé des problèmes de réservation des expéditions FedEx. Nous continuerons de surveiller la situation pendant que FedEx s'efforce de résoudre le problème. Les temps de réponse actuels de FedEx sont disponibles ici: https://www.shippingapimonitor.com/history.html?api=fedex

2. 2 septembre 2026 à 21:59 UTCresolved

   Résolue du côté FedEx.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 25 août 2026 à 14:10 UTCinvestigating

   Certains clients connaissent une lenteur avec l'accès WMS. Notre équipe enquête activement sur le problème.

2. 25 août 2026 à 16:01 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 25 août 2026 à 17:40 UTCresolved

   Cet incident a été résolu. Nous partagerons plus de détails dès qu'ils seront disponibles.

4. 27 août 2026 à 22:21 UTCpostmortem

   ## Rapport post-incident: Lenteur et erreurs WMS pour les entrepôts sur une seule base de données - 25 août 2026 ** État :** Résolue **Fenêtre d'identification:** 25 août 2026, ~04:30 - 08:45 PDT \(07:30 - 11:45 ET\) **Atteint :** Les clients dont les bases de données sont hébergées dans une instance de base de données WMS dans notre groupe d'entrepôt US-E : des temps de chargement de page allant jusqu'à 20x normale, et des erreurs intermittentes sur les écrans scanner et admin pendant la pire période. **Sans objet:** Toutes les autres instances de la base de données WMS et les groupes d'entrepôt, la plate-forme TMS, l'intégrité des données \(aucune transaction n'a été perdue, dupliquée ou partiellement appliquée\), et tous les travaux terminés - chaque transaction acceptée a été traitée correctement. Vous avez été affecté ? L'impact a été limité aux clients dont les bases de données WMS sont hébergées sur une base de données spécifique dans notre groupe US-E entrepôt, et seulement dans la matinée du 25 août \ (environ 04:30 - 08:45 PDT / 07:30 - 11:45 ET\). Si vous n'avez pas vu de charges de pages lentes dans le WMS pendant cette fenêtre, votre environnement n'a pas été impliqué. Toutes les autres instances de la base de données WMS et les groupes d'entrepôt, ainsi que toute la plate-forme TMS, ont fonctionné normalement tout au long. Résumé Dans la soirée du 24 août, un service ETL tiers qui copie les données ShipHawk dans notre entrepôt de données a redémarré un grand nombre de ses tâches de synchronisation à la fois contre une de nos bases de données de production. Chaque travail redémarré a commencé à relire un arriéré de données sur les changements historiques à pleine vitesse, en parallèle et sans limitation de taux. Le volume de lecture a grimpé à environ cinq fois le pic prévu et a consommé la plus grande partie de la bande passante disponible pour cette instance de base de données. Cela a commencé la nuit, lorsque l'activité de l'entrepôt est légère, de sorte qu'il n'a pas eu d'effet sur les opérations à l'époque. Lorsque les équipes du matin aux États-Unis et à l'Est ont commencé le 25 août, l'activité normale du WMS a été ajoutée au sommet du canal déjà saturé et l'instance a atteint sa limite de bande passante. Du point de vue de l'application, cela apparaît comme des réponses lentes à la base de données : les requêtes qui reviennent normalement en millisecondes prennent beaucoup plus de temps, les travaux sont en attente derrière eux et les pages sont chargées lentement. Lorsqu'une réponse à la base de données dépassait le délai imparti à l'application, la page renvoyait une erreur au lieu de charger. Le service est resté opérationnel tout au long de la période. Dans l'ensemble de l'instance touchée, les clients ont traité environ 70 % du volume normalement traité dans cette fenêtre \(picks, packs and inventory moves\), bien que l'expérience ait été lente et parfois difficile à travailler, et le degré d'impact a varié entre les clients. La situation s'est résolue en révoquant entièrement les références de la base de données de services ETL à 08h37 PDT. La base de données a été récupérée en huit minutes. Les travaux retardés ont traversé les deux heures suivantes, et tous les entrepôts touchés sont revenus à un rythme normal. Aucune action client n'était ou n'est requise, et aucune donnée n'a été affectée. Aucune transaction n'a été perdue, dupliquée ou partiellement appliquée - nous avons vérifié ceci contre les journaux d'intégration couvrant la fenêtre d'incident complète. Les travaux qui ont été soumis ont été effectués correctement ou ont échoué proprement avant de procéder à tout changement. Cette question est traitée plus en détail ci-dessous. Ce qui a été affecté L'impact a été limité aux clients dont les bases de données sont hébergées dans l'instance de base de données WMS touchée dans le groupe entrepôt américain-est. Tout au long de la fenêtre de l'incident, le système a été lent à travers le système - les pages de scanner et d'administration qui se chargent normalement en bien moins d'une seconde ont pris plusieurs fois plus de temps - et lorsqu'une réponse de base de données a dépassé le délai d'application, la page a retourné une erreur plutôt que de charger. À quoi cela ressemblait dans la pratique : **L'étage de l'entrepôt:** les pages du scanner \(picking, déplacement, réglage de l'inventaire\) chargé très lentement; un travailleur qui a retrié pendant qu'une page était bloquée pourrait recevoir une page d'erreur et doit retourner et répéter l'action. **Les épaves étaient concentrées dans une seule explosion plutôt que dans l'ensemble de l'incident**. La plupart d'entre eux sont tombés dans une fenêtre de 15 minutes au sommet de la congestion \(06:15 - 06:30 PDT\). Compter les pages d'erreur confirmées dans notre serveur Web et les journaux d'applications, l'entrepôt le plus touché a vu 71 dans cette fenêtre. **Le système est resté en place.** Chaque transaction soumise a été effectuée correctement ou a échoué proprement avant d'apporter un changement. Pendant la période de ralentissement la plus profonde, nous pouvons montrer des centaines de transactions réalisées avec succès pour les utilisateurs qui ont continué à travailler. Ce qui n'a pas été affecté ** Intégrité des données.** Les erreurs se sont produites au tout début du traitement des demandes, avant toute modification. Aucune transaction n'a été perdue, dupliquée ou partiellement appliquée. Nous avons vérifié les journaux d'intégration pour la fenêtre de l'incident. **La synchronisation de la commande et de l'expédition aux PGI et aux marchés** s'est effectuée correctement tout au long de la période; les affichages en attente pendant le ralentissement ont été livrés en totalité pendant le rattrapage \(vérifié dans les journaux d'intégration - pas d'affichage manqué\). **Tous les autres environnements.** Les entrepôts sur nos autres instances de base de données, et toute la plate-forme TMS, fonctionnaient normalement. ** Sécurité et location.** Aucune limite de sécurité n'était en cause à aucun moment. Le service tiers en question est un fournisseur d'intégration de données fonctionnant selon les pouvoirs que nous avons émis; la question était le volume de ses lectures, et non aucun accès non autorisé. ### Chronologie \(toutes les heures PDT; ajouter 3 heures pour ET\) Heure Événement - Oui. Le service ETL redémarre ~22 tâches de synchronisation contre la base de données dans une fenêtre de trois minutes. Chacun commence à relire les données de changement historique à pleine vitesse. Aoû 24, 22:54 - 23:50 La lecture du volume monte à environ cinq fois le pic prévu, consommant la plus grande partie de la bande passante disponible à l'instance. Le trafic d'entrepôt de nuit est léger, donc il n'y a pas encore d'effet visible du client. 25 août, ~04:30:00 Les équipes du matin de l'entrepôt américain-est commencent. La demande combinée dépasse la vitesse du réseau plafonné; les files d'attente commencent à se construire et les premières pages commencent à se rendre plus lentement que la normale. 05:30:00 Alertes automatisées de surveillance du temps d'intervention au fur et à mesure que l'activité de l'entrepôt s'accélère; les rapports des clients sur la lenteur arrivent dans la même période. L'enquête commence. 06:00 - 07:00:00 Peak congestion: connexions de base de données pic à ~15x normale que les requêtes s'accumulent; la vague d'erreurs d'écran de scanner se produit \(06:15-06:30\). Autres La cause racine identifiée : bande passante du disque sur la limite d'instance ; les flux de réplication du fournisseur identifiés comme le pilote. Le rapport interne le plus lourd est désactivé à capacité libre - le soulagement partiel. 07h20 - 08h30 Les tâches de synchronisation du service ETL sont interrompues par des ondes dans sa console et ses sessions de base de données se terminent; le service se reconnecte automatiquement en quelques secondes à chaque fois et continue à lire. Pendant cette période, il commence des emplois supplémentaires. Autres Les identifiants de la base de données du service ETL sont verrouillés et ses sessions se sont terminées une dernière fois. Les files d'attente de la base de données s'écoulent; les temps de réponse de la page reviennent à la normale. Fin de l'impact client. ### Pourquoi la résolution a pris ~3 heures des premiers rapports Trois facteurs ont prolongé le délai. Premièrement, le déclencheur est survenu sept heures avant les symptômes. La lecture du service ETL s'est déroulée du jour au lendemain et avait déjà consommé la bande passante disponible, mais avec la lumière d'activité de l'entrepôt à cette heure-là, la contrainte n'a produit qu'un léger changement dans les temps de réponse du système - en deçà de nos seuils d'alerte - donc elle est passée inaperçue. Notre surveillance automatisée a averti une fois que l'activité de l'entrepôt s'est intensifiée le matin, mais le changement sous-jacent avait alors sept heures et il n'y a eu aucun changement récent de déploiement ou de configuration. Deuxièmement, les lectures de réplication du service ETL sont invisibles aux journaux de requêtes standard de base de données - ils utilisent un protocole de réplication plutôt que des requêtes - de sorte que les identifier comme le consommateur requis corrélant disque, réseau, et niveau de connexion des preuves. Troisièmement, le service ETL est conçu pour survivre à des interruptions : le fait de quitter ses emplois et de mettre fin à ses connexions a tous deux échoué parce qu'il se reconnecte automatiquement en quelques secondes, et il a redémarré des emplois supplémentaires pendant que nous arrêtions les autres. Seul le rappel de ses références l'a arrêté. Ce que nous changeons **Tunifier les seuils d'alerte en temps de réponse au WMS.** La condition derrière cet incident était présente pendant sept heures du jour au lendemain, mais sous la charge légère il a déplacé les temps de réponse trop peu pour franchir nos seuils d'alerte - donc la première alerte est venue seulement une fois l'activité de l'entrepôt a augmenté et les clients ont déjà été touchés. Nous accordons ces seuils pour être sensibles aux changements plus petits dans le temps de réponse WMS, y compris à faible charge, de sorte que des événements comme celui-ci sont pris et mis en œuvre avant qu'ils n'atteignent les clients. Cela comprend l'alerte sur les indicateurs principaux spécifiques de cet incident - la consommation de bande passante de disque et la profondeur de file d'attente de disque. **La base de données a été migrée vers un type d'instance avec beaucoup plus de bande passante du disque**, ce qui donne une marge de manœuvre importante au-dessus de la demande maximale pour absorber des pics de ce type. **Nous poursuivons notre enquête auprès du fournisseur d'ETL.** Nous avons un cas ouvert avec eux à la recherche d'une explication pour le redémarrage simultané de l'emploi, et exigeant des limites de taux et des plafonds de concordance pour les relues contre les sources client. Ce travail est en cours.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 20 août 2026 à 14:06 UTCinvestigating

   Nous avons reçu des rapports que TMS WebPortal renvoie des erreurs ou ne charge pas pour certains clients. Nous enquêtons activement sur la question et fournirons des mises à jour au fur et à mesure que de plus amples renseignements seront disponibles.

2. 20 août 2026 à 15:02 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 20 août 2026 à 15:16 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 20 août 2026 à 18:06 UTCresolved

   Cet incident a été résolu.

5. 20 août 2026 à 19:35 UTCpostmortem

   # Rapport post-incident : Erreurs de connexion et d'API élevées - 20 août 2026 ** État :** Résolue **Fenêtre d'identification:** 20 août 2026, 06:31 - 08:11 PDT \(13:31 - 15:11 UTC\) **Affiché :** Demandes de l'API et du tableau de bord ShipHawk dans des environnements de production partagés, plus le service de connexion. L'impact a été partiel plutôt qu'une panne complète : environ 25 % du trafic total de l'API sur [shiphawk.com](http://shiphawk.com) a échoué pendant la fenêtre touchée; les taux de défaillance dans les environnements touchés ont varié d'environ 37 % à 48 %, et environ 41 % des demandes de services d'accès ont échoué. **Non affecté:** Evaluation en cours de création \(et toutes les requêtes /api/v4/rates\), traitement de fond \(tous les travaux programmés, réécriture, webhooks, génération d'étiquettes async, suivi et communications porteuses fonctionnent normalement\), intégrité des données. Résumé Le matin du 20 août, une mise à jour de sécurité critique du système d'exploitation publiée par Ubuntu - et appliquée automatiquement par notre processus de patching standard - contenait un défaut dans le composant du serveur web \(nginx\) qui se trouve devant l'application ShipHawk. Le paquet touché a été publié le 19 août sous la forme [USN-8563-3] (https://ubuntu.com/security/notices/USN-8563-3). Ubuntu a confirmé que cette mise à jour introduisait une régression et publiait [USN-8563-4](https://ubuntu.com/security/notices/USN-8563-4) le même jour, renouvelant le changement problématique en attendant une enquête plus approfondie. Alors que la version défectueuse était en cours d'exécution, la couche proxy a corrompu l'URL de nombreuses requêtes entrantes avant de les remettre à l'application. L'application ne pouvait pas correspondre aux URL corrompues à aucun paramètre connu et répondu **404 Not Found**. Les échecs étaient immédiats, des refus propres : aucune demande n'a été partiellement traitée, acheminée vers le mauvais compte ou perdue après acceptation. Nos serveurs ne téléchargent et n'installent pas tous les mises à jour de sécurité du système d'exploitation au même moment; les vérifications de mise à jour et les fenêtres d'installation sont échelonnées sur les hôtes. Par conséquent, certains serveurs ont téléchargé la compilation de nginx défectueuse avant qu'Ubuntu ne publie le paquet corrigé, tandis que d'autres ont coché plus tard et téléchargé la compilation corrigée directement. Seuls les serveurs qui avaient déjà téléchargé le paquet défectueux ont été touchés lorsque leur installation programmée a fonctionné. C'est pourquoi le problème est apparu intermittent : autrement, les requêtes identiques pourraient échouer ou réussir selon le serveur qui les a traitées. Même sur les serveurs exécutant le paquet nginx défectueux, seul un sous-ensemble de requêtes a échoué. La régression a affecté des règles spécifiques de routage nginx plutôt que l'ensemble de la configuration proxy, tant de modèles d'URL ont continué à fonctionner normalement sur un serveur affecté. L'incident a été complètement résolu par 08:11 PDT après que chaque serveur affecté a été mis à niveau pour le paquet corrigé et vérifié en bonne santé. Aucune action client n'était ou n'est requise. Ce qui a été affecté Les chiffres ci-dessous sont **seulement les échecs causés par cet incident**. Les réponses ordinaires 404 \(lookups des enregistrements qui n'existent vraiment pas, URLs invalides, trafic bot\) ont été identifiées par leur signature de réponse distincte et exclues. L'environnement L'étendue L'impact de la fenêtre \(PDT\) - Oui. Environment de sh-p-1: 2 sur 3 serveurs web: 06:34 - 08:08:37% des demandes sur les serveurs affectés; 25% du trafic API global: Service de connexion aux deux serveurs Environment de sh-p-2: 2 sur 3 serveurs web: 06:31 - 08:08:47% des demandes sur les serveurs affectés: Environment de sh-p-3: 2 de 3 serveurs web: 06:31 - 08:11:48% des demandes sur les serveurs affectés: (en milliers de dollars) À quoi cela ressemblait dans la pratique : * **Les intégrations API** ont reçu les réponses HTTP 404 pour les requêtes valides. Parce que les échecs étaient immédiats et apatrides, les relevés de clients pouvaient réussir lorsqu'ils débarquaient sur un serveur non affecté. * **Les pages de tableau de bord et de connexion** n'ont pas été chargées ou connectées de façon intermittente. * Les défaillances dépendaient de l'URL exacte : certains types de requêtes passaient sans être affectés même sur des serveurs défectueux, ajoutant à l'apparence intermittente. Ce qui n'a pas été affecté * **Demandes d'évaluation en Cart** Toutes les demandes de notation du portail Web, des plateformes de commerce électronique, des plates-formes ERP et des demandes régulières d'API adressées à `/api/v4/rates` fonctionnaient comme d'habitude. * **Les emplois de base n'ont pas été touchés du tout**. Tous les traitements asynchrones - tâches programmées, réécriture, synchronisation de l'inventaire, livraisons en ligne, génération de documents et d'étiquettes, transmissions de support et ERP - se déroulent derrière la couche proxy et se poursuivent normalement tout au long de l'incident. Aucun travail en attente n'a été perdu ou retardé. * ** Intégrité des données.** Aucune donnée n'a été perdue, altérée ou corrompue. Les demandes ont été traitées normalement ou ont été rejetées. * ** Sécurité et location.** Aucune demande n'a été acheminée vers un autre compte et aucune limite de sécurité n'a été franchie. La corruption s'est produite après l'application de tous les contrôles d'accès. La mise à jour sous-jacente d'Ubuntu était un dispositif de sécurité préventif; la vulnérabilité qu'elle a traitée n'a pas été exploitée sur nos systèmes. ## Chronologie \(toutes les heures PDT, 20 août 2026\) * **Aug 19 \(daytime\)** - Ubuntu publie une mise à jour de sécurité pour nginx; un défaut est signalé, et Ubuntu publie un paquet corrigé le même jour. La version corrigée se propage aux miroirs de mise à jour publique du jour au lendemain. * **Août 19, 18:24 - 23:09** - La mise à jour nocturne des serveurs touchés plus tard télécharge la mise à jour de la journée nginx. À ce moment, la construction défectueuse est toujours la plus récente disponible sur les miroirs. Cette étape ne télécharge que le paquet; l'installation se produit lors de la prochaine fenêtre du patch du matin. * **Ao 20, 04:12 - 05:05** - Un autre groupe de serveurs effectue sa mise à jour nocturne après que la construction corrigée a atteint les miroirs. Ces serveurs téléchargent la version fixe et restent sains tout au long de l'incident. * **~06:00** - Une mise à jour de la configuration de l'application est appliquée pour les prochaines versions. Il n'a aucun effet sur la fonctionnalité actuellement libérée et ** ne joue aucun rôle dans l'incident**, mais parce que c'est le seul changement connu ce matin, il devient le premier suspect une fois les erreurs apparaissent. * **06:00** - La fenêtre de patchage automatique nocturne commence à rouler les mises à jour nginx dans les environnements. Certains serveurs ont déjà téléchargé le paquet corrigé, tandis que d'autres ont le paquet défectueux. * **06:31 - 06:34 - INCIDENT START.** Au fur et à mesure que progresse la fenêtre de patch automatique, le paquet nginx défectueux précédemment téléchargé est installé sur plusieurs serveurs web et de connexion dans les environnements de production partagés. Parce que les horaires des patchs sont décalés, tous les serveurs ne sont pas mis à jour à la fois, et certains serveurs restent sains. Les premières demandes qui font face au client commencent à **06:31**. * **06:35** - Alertes de surveillance externe automatisées sur les erreurs élevées. **L'enquête commence immédiatement.** * **06:36 - 07:15** - Les ingénieurs étudient d'abord la mise à jour de configuration ~06:00, le seul changement connu de niveau d'application avec un timing étroitement assorti. Il est exclu, et l'attention se tourne vers la couche web/proxy. * **06:52** - La fenêtre du patch roulant continue et le paquet défectueux est activé sur des serveurs supplémentaires. L'impact augmente à mesure que les serveurs affectés redémarrent sur la version nginx défectueuse, tandis que les serveurs qui ont téléchargé le paquet corrigé d'Ubuntu restent en bonne santé. * **06:55** - Mise à jour d'un serveur web en utilisant le paquet corrigé d'Ubuntu et reste en bonne santé tout au long, continuant à servir sa part de trafic correctement. * **07:18 - 07:19** - Les serveurs Web touchés sont redémarrés comme une tentative d'atténuation. Cela n'a aucun effet parce que le paquet nginx défectueux reste installé. * **07:20 - 07:55** - Les serveurs suspects sont retirés de la rotation de l'équilibreur de charge. Les symptômes persistent parce que le service de connexion et les environnements d'application sont affectés indépendamment, ce qui élargit considérablement la recherche. * **07:41** - Le patron URL-corruption est identifié dans les journaux d'application. * **07:45 - 08:00** - Les tests par serveur isolent les serveurs défectueux. La seule différence avec les serveurs sains est la version du paquet nginx. La construction défectueuse correspond à l'avis de régression publié par Ubuntu et au paquet corrigé. * **08:02 - 08:11** - Le paquet corrigé est installé sur tous les serveurs touchés. Les taux d'erreur retournent à la normale immédiatement sur chaque serveur pendant qu'il redémarre sur la version fixe. Le dernier environnement touché revient à la normale à **08:11 - INCIDENT FULLY RESOLVED**. * **08:11\+** - La vérification complète est terminée : chaque serveur est testé individuellement, et les environnements API, tableau de bord, login et production sont confirmés en bonne santé. Pourquoi la résolution a pris ~95 minutes de l'alerte La détection était rapide, mais trois facteurs ralentissaient le diagnostic. Premièrement, un changement de configuration de routine plus tôt ce matin-là a été le seul changement connu dans l'environnement et a dû être exclu - le patchage automatique de l'OS n'apparaît dans aucun journal de changement de niveau d'application. Deuxièmement, la défaillance a été intermittente par nature : les serveurs non affectés ont continué à servir normalement, et même affectés les serveurs ont géré avec succès les types de requêtes dont les règles de routage n'ont pas été touchées. Troisièmement, le retrait des serveurs suspects de la rotation n'a pas stoppé les erreurs - parce que d'autres niveaux ont été affectés indépendamment -, ce qui a d'abord mis l'enquête hors de ces serveurs. Ce que nous changeons **1. Mise en scène des dispositifs de sécurité du système d'exploitation avant la production.** Les mises à jour automatisées de sécurité de niveau OS et nginx, y compris les correctifs critiques, seront d'abord installées sur des serveurs non-production. La validation automatique de niveau d'application exercera des chemins d'accès, API, tableau de bord et de connexion représentatifs contre les serveurs mis à jour avant que les mêmes versions de paquets soient autorisées à rouler dans la production. Le déploiement de la production ne débutera qu'après ces vérifications. **2. Diagnostic plus rapide au niveau de la version.** Nos runbooks d'incident incluent maintenant une comparaison immédiate des versions de paquets et de redémarrer l'historique sur les serveurs chaque fois que les serveurs configurés de façon identique se comportent différemment.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 26 juin 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 juin 2026 à 20:49 UTCresolved

   Resolved by FedEx

1. 19 juin 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 juin 2026 à 02:17 UTCresolved

   This incident has been resolved.

1. 18 mai 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 mai 2026 à 21:43 UTCresolved

   Resolved by PrintNode.

1. 23 février 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 février 2026 à 22:52 UTCresolved

   Resolved by FedEx.

1. 20 octobre 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 octobre 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 octobre 2025 à 23:28 UTCresolved

   The AWS issue affecting carriers has been resolved.

1. 10 octobre 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 octobre 2025 à 18:18 UTCresolved

   Resolved by USPS Endicia

1. 29 septembre 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 septembre 2025 à 22:40 UTCresolved

   Confirmed as resolved by WWEX.

1. 20 juin 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 juin 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 juin 2025 à 17:21 UTCmonitoring

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

4. 21 juin 2025 à 04:07 UTCresolved

   This incident has been resolved.

1. 5 mai 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 mai 2025 à 23:10 UTCresolved

   This incident has been resolved.

1. 14 avril 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 avril 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 avril 2025 à 20:47 UTCresolved

   This incident has been resolved.

1. 11 mars 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 mars 2025 à 12:00 UTCmonitoring

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

3. 11 mars 2025 à 22:34 UTCresolved

   This incident has been resolved.

1. 30 janvier 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 janvier 2025 à 15:59 UTCresolved

   Resolved by Pitney Bowes

1. 25 juillet 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 juillet 2024 à 20:00 UTCmonitoring

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

3. 26 juillet 2024 à 00:14 UTCresolved

   This incident has been resolved.

1. 18 juin 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 juin 2024 à 23:19 UTCresolved

   Resolved by Endicia.

1. 17 juin 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 juin 2024 à 17:01 UTCresolved

   Resolved by FedEx.

1. 22 mai 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 mai 2024 à 20:20 UTCresolved

   Resolved by FedEx team.

1. 17 mai 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 mai 2024 à 22:41 UTCresolved

   Resolved by UPS.