Störungsverlauf von Shiphawk

1. 2. September 2026 um 16:24 UTCmonitoring

   FedEx-Webdienste erleben derzeit eine beeinträchtigte Leistung, und einige Kunden haben Probleme bei der Buchung von FedEx-Sendungen gemeldet. Wir werden die Situation weiterhin überwachen, während FedEx daran arbeitet, das Problem zu lösen. Aktuelle Antwortzeiten von FedEx finden Sie hier: https://www.shippingapimonitor.com/history.html?api=fedex

2. 2. September 2026 um 21:59 UTCresolved

   Aufgelöst auf FedEx Seite.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. August 2026 um 14:10 UTCinvestigating

   Einige Kunden erleben Langsamkeit mit dem WMS-Zugang. Unser Team untersucht das Problem aktiv.

2. 25. August 2026 um 16:01 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 25. August 2026 um 17:40 UTCresolved

   Dieser Vorfall wurde behoben. Wir werden weitere Details mitteilen, sobald sie verfügbar sind.

4. 27. August 2026 um 22:21 UTCpostmortem

   ## Post-Incident Report: WMS Slowness and Errors for Warehouses on One Database Instance - 25. August 2026 **Status:** Aufgelöst **Vorfallfenster:** 25. August 2026, ~04:30 - 08:45 PDT \(07:30 - 11:45 ET\) **Betroffen:** Kunden, deren Datenbanken auf einer WMS-Datenbankinstanz in unserer US-East-Warehouse-Gruppe gehostet werden: Seitenladezeiten von bis zu 20x normal und intermittierende Fehler auf Scanner- und Admin-Bildschirmen während der schlimmsten Zeit. **Nicht betroffen:** Alle anderen WMS-Datenbankinstanzen und Lagergruppen, die TMS-Plattform, Datenintegrität (keine Transaktion wurde verloren, dupliziert oder teilweise angewendet) und alle abgeschlossenen Arbeiten - jede akzeptierte Transaktion wurde korrekt verarbeitet. ### Waren Sie betroffen? Die Auswirkungen beschränkten sich auf Kunden, deren WMS-Datenbanken in einer bestimmten Datenbankinstanz in unserer Lagergruppe US-East gehostet werden, und zwar nur am Morgen des 25. August (ca. 04:30 - 08:45 PDT / 07:30 - 11:45 ET). Wenn Sie während dieses Fensters keine langsamen Seitenladungen im WMS gesehen haben, war Ihre Umgebung nicht beteiligt. Alle anderen WMS-Datenbankinstanzen und Lagergruppen sowie die gesamte TMS-Plattform funktionierten durchgehend normal. ### Zusammenfassung Am Abend des 24. August hat ein ETL-Dienst eines Drittanbieters, der ShipHawk-Daten in unser Data Warehouse kopiert, eine große Anzahl seiner Synchronisierungsaufträge auf einmal gegen eine unserer Produktionsdatenbanken neu gestartet. Jeder neu gestartete Job begann, einen Rückstand historischer Änderungsdaten mit voller Geschwindigkeit parallel und ohne Ratenbegrenzung erneut zu lesen. Das Lesevolumen stieg auf etwa das Fünffache des erwarteten Peaks und verbrauchte den größten Teil der für diese Datenbankinstanz verfügbaren Festplattenbandbreite. Dies begann über Nacht, wenn die Lageraktivität leicht ist, so dass sie sich zu diesem Zeitpunkt nicht auf den Betrieb auswirkte. Als die Morgenschichten zwischen den USA und dem Osten am 25. August begannen, wurde die normale WMS-Aktivität auf dem bereits gesättigten Kanal hinzugefügt und die Instanz erreichte ihre Bandbreitengrenze. Aus der Sicht der Anwendung erschien dies als langsame Datenbankantworten: Abfragen, die normalerweise in Millisekunden zurückkehren, dauerten viel länger, die Arbeit stand hinter ihnen an und Seiten wurden langsam geladen. Wenn eine Datenbankantwort das Timeout der Anwendung überschritten hat, hat die Seite einen Fehler zurückgegeben, anstatt geladen zu werden. Der Service blieb während des gesamten Betriebs. In der betroffenen Instanz verarbeiteten die Kunden etwa 70% des Volumens, das normalerweise in diesem Fenster gehandhabt wurde (Picks, Packs und Inventarbewegungen), obwohl die Erfahrung langsam und manchmal schwierig war und der Grad der Auswirkungen zwischen den Kunden variierte. Die Situation wurde durch den vollständigen Widerruf der ETL-Dienstdatenbankanmeldeinformationen um 08:37 PDT behoben. Die Datenbank erholte sich innerhalb von acht Minuten. Verzögerte Arbeiten spülten in den folgenden zwei Stunden durch, und alle betroffenen Lagerhallen waren wieder normal. Es war oder ist keine Kundenaktion erforderlich und es waren keine Daten betroffen. Keine Transaktion wurde verloren, dupliziert oder teilweise angewendet - wir haben dies mit Integrationsprotokollen überprüft, die das gesamte Ereignisfenster abdecken. Arbeiten, die entweder korrekt abgeschlossen wurden oder sauber fehlgeschlagen sind, bevor Änderungen vorgenommen wurden. Darauf wird weiter unten näher eingegangen. ### Was war betroffen Die Auswirkungen beschränkten sich auf Kunden, deren Datenbanken in der betroffenen WMS-Datenbankinstanz der US-East-Warehouse-Gruppe gehostet werden. Während des gesamten Incident-Fensters war das System auf der ganzen Linie langsam - Scanner- und Admin-Seiten, die normalerweise weit unter einer Sekunde geladen werden, dauerten um ein Vielfaches länger - und wenn eine Datenbankantwort das Anwendungs-Timeout überschritt, gab die Seite einen Fehler zurück, anstatt zu laden. Wie das in der Praxis aussah: **Warehouse Floor: ** Scannerseiten \(picken, verschieben, Inventar anpassen \) sehr langsam geladen; ein Mitarbeiter, der wiederholte, während eine Seite stecken blieb, konnte eine Fehlerseite erhalten und muss zurückgehen und die Aktion wiederholen. **Fehler wurden in einem einzigen Burst konzentriert, anstatt sich über den Vorfall zu verbreiten. ** Die meisten von ihnen fielen innerhalb eines 15-Minuten-Fensters auf dem Höhepunkt der Staus \(06:15 - 06:30 PDT\). Zählt man bestätigte Fehlerseiten in unseren Webserver- und Anwendungsprotokollen, sah das am stärksten betroffene Lager 71 in diesem Fenster. ** Das System blieb durchweg auf. ** Jede eingereichte Transaktion wurde entweder korrekt abgeschlossen oder ist sauber fehlgeschlagen, bevor Änderungen vorgenommen wurden. Während des tiefsten Verlangsamungsfensters können wir Hunderte von Transaktionen zeigen, die für die Benutzer, die weiter gearbeitet haben, erfolgreich abgeschlossen wurden. ### Was NICHT betroffen war **Datenintegrität.** Die Fehler traten zu Beginn der Anforderungsverarbeitung auf, bevor eine Änderung vorgenommen wurde. Keine Transaktion wurde verloren, dupliziert oder teilweise angewendet. Jede abgeschlossene Fulfillment-, Inventarbewegung und Sendungsposting hat dies korrekt getan - wir haben die Integrationsprotokolle für das Ereignisfenster überprüft. **Order- und Sendungssynchronisation zu ERPs und Marktplätzen** korrekt abgeschlossen; Postings, die während der Verlangsamung Schlange standen, wurden während des Aufholvorgangs vollständig geliefert \(verifiziert in Integrationsprotokollen - keine fehlgeschlagenen Postings\). ** Alle anderen Umgebungen.** Lagerhäuser auf unseren anderen Datenbankinstanzen und die gesamte TMS-Plattform funktionierten normal. **Sicherheit und Miete.** Keine Sicherheitsgrenze war zu irgendeinem Zeitpunkt beteiligt. Der betreffende Drittanbieter-Dienst ist ein Datenintegrationsanbieter, der unter von uns ausgestellten Anmeldeinformationen arbeitet; Das Problem war das Volumen seiner Lesevorgänge, kein unbefugter Zugriff. ### Timeline \(alle Zeiten PDT; fügen Sie 3 Stunden für ET\) Uhrzeit | Veranstaltung | | --- | --- | 24. August, 22:54 - 22:57 | Der ETL-Dienst startet ~22 Synchronisierungsaufträge mit der Datenbank innerhalb eines dreiminütigen Fensters neu. Jeder beginnt, historische Änderungsdaten mit voller Geschwindigkeit erneut zu lesen. | 24. August, 22:54 - 23:50 | Das Lesevolumen steigt auf etwa das Fünffache des erwarteten Peaks und verbraucht den größten Teil der für die Instanz verfügbaren Festplattenbandbreite. Der Übernachtungs-Lagerverkehr ist leicht, so dass es noch keinen Kunden-sichtbaren Effekt gibt. | Aug 25, ~04:30 | US-East Lager Morgenschichten beginnen. Die kombinierte Nachfrage übersteigt die gedeckelte Netzwerkgeschwindigkeit; Warteschlangen beginnen zu bauen und die ersten Seiten beginnen, langsamer als normal zu rendern. | 05:30 | Automatisierte Warnmeldungen zur Reaktionszeitüberwachung, wenn die Lageraktivität ansteigt; Kundenberichte über Langsamkeit kommen im gleichen Zeitraum an. Die Untersuchung beginnt. | | 06:00 - 07:00 | Spitzenstauung: Datenbankverbindungen steigen auf ~15x normal, wenn sich Anfragen häufen; die Welle von Scanner-Bildschirmfehlern tritt auf \(06:15-06:30\). | | 06:50 | Ursache identifiziert: Festplattenbandbreite über dem Instanzlimit; Replikationsströme des Anbieters als Treiber identifiziert. | | 07:00 | Schwerste interne Berichtsabfragen deaktiviert auf freie Kapazität - teilweise Entlastung. | | 07:20 - 08:30 | ETL-Service-Sync-Jobs werden in Wellen in der Konsole angehalten und die Datenbanksitzungen beendet; der Dienst verbindet sich jedes Mal automatisch innerhalb von Sekunden wieder und liest weiter. Während dieser Zeit beginnt es zusätzliche Arbeitsplätze. | | 08:35 | Die Anmeldeinformationen der ETL-Dienstdatenbank sind gesperrt und ihre Sitzungen werden ein letztes Mal beendet. | | 08:38 - 08:45 | Datenbank-Warteschlangen ablaufen; Seitenantwortzeiten kehren zum Normalzustand zurück. Customer Impact endet. | ### Warum die Lösung ~3 Stunden von den ersten Berichten dauerte Drei Faktoren erweiterten die Timeline. Zuerst trat der Auslöser sieben Stunden vor den Symptomen auf. Das erneute Lesen des ETL-Dienstes lief über Nacht und hatte bereits die verfügbare Bandbreite verbraucht, aber mit Lageraktivitätslicht zu dieser Stunde führte die Einschränkung nur zu einer geringfügigen Änderung der Systemreaktionszeiten - unterhalb unserer Alarmschwellen - so dass es unentdeckt blieb. Unsere automatisierte Überwachung hat alarmiert, sobald die Lageraktivität am Morgen hochgefahren war, aber bis dahin war die zugrunde liegende Änderung sieben Stunden alt und es gab keine kürzliche Bereitstellung oder Konfigurationsänderung, auf die man zeigen konnte. Zweitens sind die Replikationslesungen des ETL-Dienstes für Standard-Datenbankabfrageprotokolle unsichtbar - sie verwenden ein Replikationsprotokoll anstelle von Abfragen - und identifizieren sie daher als den benötigten Benutzer, der Datenträger, Netzwerk und Beweise auf Verbindungsebene korreliert. Drittens ist der etl-dienst so konzipiert, dass er unterbrechungen übersteht: das pausieren seiner jobs und das beenden seiner verbindungen scheiterten beide als abschwächung, weil er sich innerhalb von sekunden automatisch wieder verbindet, und er hat zusätzliche jobs neu gestartet, während wir andere pausierten. Nur der Widerruf seiner Referenzen stoppte es. ### Was wir verändern **Tuning WMS Response-Time Alarmschwellen.** Der Zustand hinter diesem Vorfall war sieben Stunden über Nacht vorhanden, aber unter leichter Last verschob er die Reaktionszeiten zu wenig, um unsere Alarmschwellen zu überschreiten - so kam der erste Alarm erst, als die Lageraktivitäten hochgefahren waren und die Kunden bereits betroffen waren. Wir stimmen diese Schwellenwerte so ab, dass sie empfindlich auf kleinere Verschiebungen der WMS-Reaktionszeit reagieren, auch bei geringer Last, so dass Ereignisse wie diese erfasst und bearbeitet werden, bevor sie Kunden erreichen. Dazu gehört die Warnung vor den spezifischen Hauptindikatoren dieses Vorfalls - Datenträgerbandbreitenverbrauch und Datenträgerwarteschlange. **Die Datenbank wurde zu einem Instanztyp mit wesentlich mehr Festplattenbandbreite migriert **, was eine erhebliche Headroom über der Spitzennachfrage nach Spikes dieser Art gibt. **Wir setzen unsere Untersuchung mit dem ETL-Anbieter fort.** Wir haben einen offenen Fall mit ihnen, um eine Erklärung für den gleichzeitigen Neustart des Auftrags zu suchen, und erfordern Preisbegrenzungs- und Parallelitätsobergrenzen für Wiederholungslesungen gegen Kundenquellen. Diese Arbeit geht weiter.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. August 2026 um 14:06 UTCinvestigating

   Wir haben Berichte erhalten, dass TMS WebPortal Fehler zurückgibt oder einige Kunden nicht laden kann. Wir untersuchen das Problem aktiv und werden Updates bereitstellen, sobald mehr Informationen verfügbar sind.

2. 20. August 2026 um 15:02 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 20. August 2026 um 15:16 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 20. August 2026 um 18:06 UTCresolved

   Dieser Vorfall wurde behoben.

5. 20. August 2026 um 19:35 UTCpostmortem

   # Post-Incident Report: Erhöhte API- und Login-Fehler - 20. August 2026 **Status:** Aufgelöst **Vorfallfenster:** August 20, 2026, 06:31 - 08:11 PDT \(13:31 - 15:11 UTC\) **Betroffen:** ShipHawk API- und Dashboard-Anfragen in freigegebenen Produktionsumgebungen sowie den Anmeldeservice. Die Auswirkungen waren eher teilweise als ein vollständiger Ausfall: Etwa 25% des gesamten API-Datenverkehrs auf [shiphawk.com] (http://shiphawk.com) scheiterten während des betroffenen Fensters; die Fehlerquoten in den betroffenen Umgebungen reichten von etwa 37% bis 48% und etwa 41% der Login-Service-Anfragen scheiterten. **Nicht betroffen: ** In-Cart-Bewertung \(und alle /api/v4/rate-Anfragen \), Hintergrundverarbeitung \(alle geplanten Jobs, Rückschreibungen, Webhooks, async-Label-Generierung, Tracking und Carrier-Kommunikation liefen normal\), Datenintegrität. ## Zusammenfassung Am Morgen des 20. August enthielt ein Betriebssystem-kritisches Sicherheitsupdate, das von Ubuntu veröffentlicht und automatisch von unserem Standard-Patching-Prozess angewendet wurde, einen Defekt in der Webserver-Komponente (nginx), die sich vor der ShipHawk-Anwendung befindet. Das betroffene Paket wurde am 19. August unter [USN-8563-3] (https://ubuntu.com/security/notices/USN-8563-3) veröffentlicht. Ubuntu bestätigte, dass dieses Update eine Regression einführte und veröffentlichte [USN-8563-4](https://ubuntu.com/security/notices/USN-8563-4) am selben Tag, wodurch die problematische Änderung bis zur weiteren Untersuchung rückgängig gemacht wurde. Während die fehlerhafte Version ausgeführt wurde, beschädigte die Proxyschicht die URL vieler eingehender Anfragen, bevor sie sie an die Anwendung weiterleitete. Die Anwendung konnte die beschädigten URLs nicht mit einem bekannten Endpunkt abgleichen und antwortete **404 Not Found**. Die Fehler waren sofortige, saubere Ablehnungen: keine Anfrage wurde teilweise bearbeitet, auf das falsche Konto weitergeleitet oder nach der Annahme verloren. Unsere Server laden nicht alle Betriebssystem-Sicherheitsupdates gleichzeitig herunter und installieren sie; Update-Checks und Installationsfenster sind über Hosts gestaffelt. Infolgedessen haben einige Server den fehlerhaften nginx-Build heruntergeladen, bevor Ubuntu das korrigierte Paket veröffentlicht hat, während andere später überprüft und den korrigierten Build direkt heruntergeladen haben. Nur die Server, die das fehlerhafte Paket bereits heruntergeladen hatten, waren betroffen, als ihre geplante Installation lief. Aus diesem Grund erschien das Problem intermittierend: ansonsten identische Anfragen könnten fehlschlagen oder erfolgreich sein, je nachdem, welcher Server sie bearbeitet hat. Selbst auf Servern, auf denen das fehlerhafte nginx-Paket ausgeführt wird, ist nur eine Teilmenge der Anforderungen fehlgeschlagen. Die Regression betraf spezifische nginx-Routing-Regeln und nicht die gesamte Proxy-Konfiguration, so dass viele URL-Muster weiterhin normal auf einem betroffenen Server funktionierten. Der Vorfall wurde bis 08:11 PDT vollständig behoben, nachdem jeder betroffene Server auf das korrigierte Paket aktualisiert und als gesund verifiziert wurde. Keine Kundenaktion war oder ist erforderlich. ## Was betroffen war Die folgenden Zahlen zählen **nur Ausfälle, die durch diesen Vorfall verursacht wurden**. Gewöhnliche 404-Antworten (Lookups von Datensätzen, die wirklich nicht existieren, ungültige URLs, Bot-Traffic) wurden durch ihre eindeutige Antwortsignatur identifiziert und ausgeschlossen. | Environment | Scope | Impacted window \(PDT\) | Failed requests | | --- | --- | sh-p-1-Umgebung | 2 von 3 Webservern | 06:34 - 08:08 | ≈37% der Anfragen auf betroffenen Servern; ≈25% des gesamten API-Traffics | | Login-Service | Beide Server | 06:33 - 08:08 | ≈41% der Login-Service-Anfragen | | sh-p-2-Umgebung | 2 von 3 Webservern | 06:31 - 08:08 | ≈47% der Anfragen auf betroffenen Servern | | sh-p-3-Umgebung | 2 von 3 Webservern | 06:31 - 08:11 | ≈48% der Anfragen auf betroffenen Servern | Wie das in der Praxis aussah: * **API-Integrationen** erhielten HTTP 404-Antworten für gültige Anfragen. Da Fehler sofort und zustandslos waren, konnten Client-Retries erfolgreich sein, wenn sie auf einem nicht betroffenen Server landeten. * **Dashboard- und Login-Seiten konnten nicht intermittierend geladen oder angemeldet werden. * Ausfälle hingen von der genauen URL ab: Einige Anforderungstypen wurden auch auf fehlerhaften Servern nicht beeinflusst und fügten dem intermittierenden Erscheinungsbild hinzu. ## Was NICHT betroffen war * **In-Cart-Bewertungsanfragen.** Alle Rating-Anfragen vom Webportal, E-Commerce-Plattformen, ERP-Plattformen und regelmäßigen API-Anfragen an `/api/v4/rates` funktionierten wie gewohnt. * **Hintergrundjobs waren überhaupt nicht betroffen. ** Die gesamte asynchrone Verarbeitung - geplante Aufträge, Rückschreibungen, Bestandssynchronisierung, Webhook-Lieferungen, Dokumenten- und Etikettenerzeugung, Carrier- und ERP-Kommunikation - läuft hinter der Proxy-Schicht und wird während des gesamten Vorfalls normal fortgesetzt. Keine Schlangenarbeit ging verloren oder verzögerte sich. ***Datenintegrität.** Keine Daten wurden verloren, verändert oder beschädigt. Anträge wurden entweder normal ausgefüllt oder direkt abgelehnt. * **Sicherheit und Miete.** Keine Anfrage wurde an ein anderes Konto weitergeleitet und keine Sicherheitsgrenze überschritten. Die Korruption trat auf, nachdem alle Zugangskontrollen angewendet wurden. Das zugrunde liegende Ubuntu-Update war ein präventiver Sicherheits-Patch; die Schwachstelle, die es angesprochen hat, wurde auf unseren Systemen nicht ausgenutzt. ## Timeline \(alle Zeiten PDT, August 20, 2026\) * **Aug 19 \(daytime\)** - Ubuntu veröffentlicht ein Sicherheitsupdate für nginx; ein Defekt wird gemeldet, und Ubuntu veröffentlicht am selben Tag ein korrigiertes Paket. Die korrigierte Version wird über Nacht in öffentliche Update-Spiegel übertragen. * **Aug 19, 18:24 - 23:09** - Die nächtlichen Update-Checks auf den später betroffenen Servern laden das nginx-Update des Tages herunter. In diesen Momenten ist der fehlerhafte Build immer noch der neueste auf den Spiegeln. Dieser Schritt lädt nur das Paket herunter; die Installation erfolgt während des Patch-Fensters am nächsten Morgen. * **Aug 20, 04:12 - 05:05** - Eine andere Gruppe von Servern führt ihren nächtlichen Update-Check durch, nachdem der korrigierte Build die Spiegel erreicht hat. Diese Server laden die feste Version herunter und bleiben während des gesamten Vorfalls gesund. * **~06:00** - Eine Routine-Aktualisierung der Anwendungskonfiguration wird für kommende Releases angewendet. Es hat keinen Einfluss auf die derzeit veröffentlichte Funktionalität und spielt keine Rolle in dem Vorfall, aber weil es die einzige bekannte Änderung an diesem Morgen ist, wird es der erste Verdächtige, sobald Fehler auftreten. * **06:00** - Das nächtliche automatische Patching-Fenster beginnt, nginx-Updates in allen Umgebungen zu rollen. Einige Server haben bereits das korrigierte Paket heruntergeladen, während andere das fehlerhafte Paket haben. * **06:31 - 06:34 - INNCIDENT START.** Während das automatische Patchfenster fortschreitet, wird das zuvor heruntergeladene fehlerhafte nginx-Paket auf mehreren Web- und Anmeldeservern in gemeinsamen Produktionsumgebungen installiert. Da Patch-Zeitpläne gestaffelt sind, aktualisieren nicht alle Server auf einmal und einige Server bleiben gesund. Die ersten gescheiterten Kundenanfragen beginnen um **06:31**. * **06:35** - Automatisierte externe Überwachungsalarme bei erhöhten Fehlern. **Die Untersuchung beginnt sofort.** * **06:36 - 07:15** - Ingenieure untersuchen zuerst das ~06:00 Konfigurationsupdate, die einzige bekannte Änderung auf Anwendungsebene mit genau übereinstimmendem Timing. Es ist ausgeschlossen, und die Aufmerksamkeit richtet sich auf die Web / Proxy-Schicht. * **06:52** - Das rollende Patchfenster geht weiter und das fehlerhafte Paket wird auf zusätzlichen Servern aktiviert. Die Auswirkungen steigen, wenn mehr betroffene Server auf die fehlerhafte nginx-Version neu starten, während Server, die das korrigierte Paket von Ubuntu heruntergeladen haben, gesund bleiben. * **06:55** - Ein verbleibender Webserver aktualisiert das korrigierte Paket von Ubuntu und bleibt durchweg gesund und bedient weiterhin seinen Anteil am Datenverkehr korrekt. * **07:18 - 07:19** - Betroffene Webserver werden als Minderungsversuch neu gestartet. Dies hat keine Auswirkungen, da das fehlerhafte nginx-Paket weiterhin installiert bleibt. * **07:20 - 07:55** - Verdächtige Server werden aus der Load-Balancer-Rotation entfernt. Die Symptome bestehen fort, da die Anmeldedienst- und Anwendungsumgebungen unabhängig voneinander betroffen sind, was die Suche erheblich erweitert. * **07:41** - Das URL-Korruptionsmuster wird in den Anwendungsprotokollen identifiziert. * **07:45 - 08:00** - Pro-Server-Tests isolieren die fehlerhaften Server. Der einzige Unterschied zu gesunden Servern ist die nginx-Paketversion. Der fehlerhafte Build wird mit der veröffentlichten Regressionsanzeige und dem korrigierten Paket von Ubuntu abgeglichen. * **08:02 - 08:11** - Das korrigierte Paket wird auf allen betroffenen Servern installiert. Die Fehlerraten kehren sofort auf jedem Server zum Normalzustand zurück, wenn er auf die feste Version neu gestartet wird. Die endgültige betroffene Umgebung kehrt um **08:11 Uhr zur Normalität zurück - INCIDENT FULLY RESOLVED**. * **08:11\+** - Die vollständige Verifizierung ist abgeschlossen: Jeder Server wird individuell getestet und API, Dashboard, Login und Produktionsumgebungen werden als gesund bestätigt. Warum Auflösung dauerte ~ 95 Minuten von Alarm Die Erkennung war schnell, aber drei Faktoren verlangsamten die Diagnose. Erstens war eine routinemäßige Konfigurationsänderung früher am Morgen die einzige bekannte Änderung in der Umgebung und musste ausgeschlossen werden - automatisiertes OS-Patching erscheint in keinem Änderungsprotokoll auf Anwendungsebene. Zweitens war der Fehler von Natur aus intermittierend: Nicht betroffene Server dienten weiterhin normal und sogar betroffene Server behandelten erfolgreich Anforderungstypen, deren Routing-Regeln nicht betroffen waren. Drittens hat das Entfernen der verdächtigen Server aus der Rotation die Fehler nicht gestoppt - weil andere Ebenen unabhängig voneinander betroffen waren - was die Untersuchung ursprünglich von diesen Servern wegwies. ## Was wir verändern **1. Sicherheitspatches für Betriebssysteme vor der Produktion.** Automatisierte Sicherheitsupdates auf OS- und nginx-Ebene, einschließlich kritischer Patches, werden zunächst auf Nicht-Produktionsservern installiert. Die automatisierte Validierung auf Anwendungsebene führt zu repräsentativen API-, Dashboard- und Anmeldepfaden für die aktualisierten Server, bevor die gleichen Paketversionen in Produktion gehen dürfen. Der Rollout der Produktion beginnt erst, nachdem diese Kontrollen bestanden wurden. **2. Schnellere Versionsdiagnose.** Unsere Incident Runbooks beinhalten nun einen sofortigen Vergleich der Paketversionen und den Neustartverlauf über Server hinweg, wenn sich identisch konfigurierte Server unterschiedlich verhalten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

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

   Resolved by FedEx

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

   This incident has been resolved.

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

   Resolved by PrintNode.

1. 23. Februar 2026 um 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 um 22:52 UTCresolved

   Resolved by FedEx.

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

   The AWS issue affecting carriers has been resolved.

1. 10. Oktober 2025 um 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 um 18:18 UTCresolved

   Resolved by USPS Endicia

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

   Confirmed as resolved by WWEX.

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

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

4. 21. Juni 2025 um 04:07 UTCresolved

   This incident has been resolved.

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

   This incident has been resolved.

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

   This incident has been resolved.

1. 11. März 2025 um 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. März 2025 um 12:00 UTCmonitoring

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

3. 11. März 2025 um 22:34 UTCresolved

   This incident has been resolved.

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

   Resolved by Pitney Bowes

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

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

3. 26. Juli 2024 um 00:14 UTCresolved

   This incident has been resolved.

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

   Resolved by Endicia.

1. 17. Juni 2024 um 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 um 17:01 UTCresolved

   Resolved by FedEx.

1. 22. Mai 2024 um 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 um 20:20 UTCresolved

   Resolved by FedEx team.

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

   Resolved by UPS.