Shiphawk kesinti geçmişi

1. 2 Eylül 2026 16:24 UTCmonitoring

   BP web hizmetleri şu anda bozulan performansı deneyimliyor ve bazı müşteriler BP gönderilerini rezervasyonu rapor etti. Biz durumu izlemeye devam edeceğiz, ancak BP sorunu çözmeye çalışır. Şu anki BP yanıt süreleri burada mevcuttur: https://www.shippingapimonitor.com/history.html?api=fedex

2. 2 Eylül 2026 21:59 UTCresolved

   2003 yılında yeniden çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 25 Ağustos 2026 14:10 UTCinvestigating

   Bazı müşteriler WMS erişimi ile yavaşlık yaşıyor. Ekibimiz konuyu aktif olarak araştırıyor.

2. 25 Ağustos 2026 16:01 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

3. 25 Ağustos 2026 17:40 UTCresolved

   Bu olay çözüldü. Mevcut oldukları sürece daha fazla ayrıntı paylaşacağız.

4. 27 Ağustos 2026 22:21 UTCpostmortem

   ## Post-Incident Report: WMS Slowness ve Hatalar One Database Instance - 25 Ağustos 2026 **Status:** Çözüldü **Incident penceresi: ** 25 Ağustos 2026, ~04:30 - 08:45 PDT \ (07:30 - 11:45 ET\) **Affected:** Veritabanları ABD-Doğu depo grubumuzda bir WMS veritabanında barındırılan müşteriler: sayfa 20x normale kadar yük süreleri ve en kötü dönemde tarayıcı ve yönetim ekranlarında aralıklı hatalar. ** Etkilenme:** Diğer tüm WMS veritabanı örnekleri ve depo grupları, TMS platformu, veri bütünlüğü \(no işlemi kayboldu, tekrarlandı veya kısmen uygulandı), ve tüm tamamlanmış iş - kabul edilen her işlem doğru şekilde işlendi. # # ## Etkilendin mi? WMS veritabanının ABD-Doğu depo grubumuzda belirli bir veritabanında barındırıldığı müşteriler ile sınırlıydı ve sadece 25 Ağustos sabahı (yaklaşık 04:30 - 08:45 PDT / 07:30 - 11:45 ET\). Bu pencere sırasında WMS'deki yavaş sayfa yüklerini görmediyseniz, ortamınız dahil edilmedi. Diğer tüm WMS veritabanı örnekleri ve depo grupları ve tüm TMS platformu normalde boyunca çalışır. # ### Özet 24 Ağustos gecesi, gemiHawk verilerini veri depolarımıza geri veren üçüncü taraf ETL hizmeti, üretim veri tabanımızdan birine karşı bir kez senkronize etti. Her yeniden başlayan iş, tam hızda, paralel olarak ve herhangi bir oran sınırlaması olmadan tekrar tarihsel değişim verilerini yeniden hazırlamaya başladı. Bu veritabanı örneğine mevcut disk bant genişliğinin çoğunu yaklaşık beş kez tırmanmayı ve tükettiğini okuyun. Bu bir gecede başladı, depo aktivitesinin ışık olduğu zaman, bu yüzden zamanında operasyonların hiçbir etkisi yoktu. ABD-Doğu sabah değişimleri 25 Ağustos'ta başladığında, normal WMS aktivitesi zaten doymamış kanalın üstüne eklenmiştir ve örneğin bant limitine ulaştı. Uygulamanın bakış açısından bu yavaş veritabanı yanıtları olarak ortaya çıktı: normalde milisaniyelerde geri dönen sorgular daha uzun sürdü, onları geride bıraktı ve yavaş yüklenen sayfalar. Bir veritabanı yanıtı uygulamanın zamanını aştığında, sayfa yükleme yerine bir hata geri döndü. Servis her zaman operasyonel kaldı. Etkilenen örnekte, müşteriler normalde bu pencerede \ (örneğin, paketler ve envanter hareketleri) ele geçirilen hacmin yaklaşık% 70'ini işlediler, ancak deneyim yavaş ve zamanla müşteriler arasında çeşitli etki derecesi elde etti. Durum, ETL servis veritabanı bilgilerini tamamen 08:37 PDT'de iptal ederek çözüldü. Veritabanı sekiz dakika içinde kurtarıldı. Gecikmiş çalışma, aşağıdaki iki saat boyunca kızdı ve tüm etkilenen depolar normal hızda geri döndü. Hiçbir müşteri eylemi gerekli veya gerekli değildi ve hiçbir veri etkilenmedi. Hiçbir işlem kaybedilmedi, tekrarlandı ya da kısmen uygulandı - tam olay penceresini kapsayan entegrasyon loglarına karşı bunu doğruladık. Bu, herhangi bir değişiklik yapmadan önce doğru veya başarısız bir şekilde teslim edildi. Bu aşağıda daha ayrıntılı olarak kaplıdır. ### Etkilendiren şey Etkisi, veritabanının ABD-Doğu depo grubunda etkilenen WMS veritabanında barındırıldığı müşteriler ile sınırlıydı. Olay penceresi boyunca sistem gemide yavaştı - tarayıcı ve yönetici sayfalar normalde ikinci olarak yüklenen birçok kez daha uzun sürdü - ve bir veritabanı yanıtı uygulama süresini aştı, sayfa yüklemeden ziyade bir hata geri döndü. Bu pratikte neye benziyordu: **Warehouse zemin: ** tarayıcı sayfaları \ (örneğin, hareket etmek, envanter ayarlaması) çok yavaş yüklenen bir işçi; bir sayfa bir hata sayfası alıp geri dönmek ve eylemi tekrarlamak zorunda kaldı. **Errors, olayda yayılmak yerine tek bir patlamada yoğunlaşıyordu. **Errors was intense in a single burst rather than spread across the event.** Bunların çoğu, kongestion \(06:15 - 06:30 PDT\) zirvede 15 dakikalık bir pencerede düştü. Web sunucumuzda ve uygulama loglarımızda doğrulanan hata sayfaları, en çok etkilenen depo bu pencerede 71 gördü. ** Sistem sürekli kaldı.** Her teklif işlemi herhangi bir değişiklik yapmadan önce doğru veya başarısız bir şekilde tamamladı. En derin yavaşlama penceresi sırasında, çalışmaya devam eden kullanıcılar için başarıyla tamamlanmış yüzlerce işlem gösterebiliriz. ### Ne etkilenmedi **Veri bütünlüğü.** Hatalar, herhangi bir değişiklik yapılmadan önce talep işlemenin çok başlangıcında gerçekleşti. Hiçbir işlem kayboldu, tekrarlandı veya kısmen uygulandı. Her yerine, envanter hareket eder ve tamamlanmış gönderileri doğru bir şekilde yaptı - olay penceresi için entegrasyon loglarını doğruladık. ** ERP'lere ve marketlere senkronizasyon; sürekli olarak tamamlandı; Yavaşlama sırasında kuyrukların teslim edildikleri yayınlar, \(ilişleme girişlerinde) tam olarak teslim edildi. ** Tüm diğer ortamlar. ** Diğer veritabanı örneklerimizdeki depolar ve tüm TMS platformu normalde işletildi. ** Güvenlik ve onancy. ** Hiçbir güvenlik sınırı herhangi bir noktada dahil edilmedi. Sorudaki üçüncü taraf hizmet, yayınladığımız kimlikler altında çalışan bir veri toplama satıcısıdır; konu okumalarının hacmiydi, yetkisiz erişim değildi. ## Timeline \ (tüm zamanlar PDT; ET\ için 3 saat ekleyin) | Time | Event | | --- | | Aug 24, 22:54 - 22:57 | ETL hizmeti yeniden başlar - veritabanına üç dakikalık bir pencere içinde senkronize edilir. Her biri tam hızda tarihsel değişim verilerini yeniden okumaya başlar. | | Aug 24, 22:54 - 23:50 | Başlangıç hacmi beklenen zirveye tırmanmak, örneğin mevcut disk bant genişliğinin çoğunu tüketmek. Gece içi depolama trafiği ışıktır, bu yüzden henüz müşteri odaklı bir etki yoktur. | 25 Ağustos - 04:30 | ABD-Doğu Deposu sabah değişimleri başlıyor. Kombinasyon talebi kaplanan ağ hızını aşıyor; kuyruklar binaya başlıyor ve ilk sayfalar normalden daha yavaş yavaş başlıyor. | | 05:30 | Otomatik yanıt-zaman izleme uyarıları depo aktivite rampaları olarak kaydeder; müşteri yavaşlığın raporları aynı dönemde gelir. İnceleme başlar. | | 06:00 - 07:00 | Peak congestion: veritabanı bağlantıları yığın olarak ~15x normale yükseldi; tarayıcı ekran hataları dalgası \(06:15-06:30\). | | 06:50 | Kök neden tespit edildi: Örnek limit üzerindeki disk bant genişliği; satıcının replikasyon akışları sürücü olarak tespit edildi. | | 07:00 | Heaviest internal rapor sorguları ücretsiz kapasiteye - kısmi rahatlamaya engel. | | 07:20 - 08:30 | ETL hizmeti senkronizasyon işleri konsoldaki dalgalarda duraklanır ve veritabanı oturumları sona erer; hizmet her seferinde otomatik olarak yeniden bağlantı kurar ve okumaya devam eder. Bu dönemde ek işler başlar. | 08:35 | ETL servis veritabanı kimlikleri kilitlenir ve seansları son bir kez sona erer. | 08:38 - 08:45 | Veritabanı kuyrukları yok; sayfa yanıt süreleri normale geri döner. Müşteri etkisi sona erer. | # ## Karar ilk raporlardan ~3 saat sürdü Üç faktör süresi uzatmıştır. İlk olarak, tetikleyici semptomlardan yedi saat önce meydana geldi. ETL hizmetinin yeniden hazırlandığı bir gecede koştu ve zaten mevcut bant genişliğini tüketmişti, ancak bu saat içinde depo aktivitesi ışığıyla, sistem yanıt zamanlarında sadece hafif bir değişiklik üretti - uyarı eşlerimiz altında - bu yüzden tespit edilmedi. Otomatik izlememiz, sabahları bir kez depo faaliyetleri hızlandırdı, ancak daha sonra temel değişim yedi saat eskiydi ve yeni bir dağıtım veya yapılandırma değişikliği söz konusu değildi. İkincisi, ETL hizmetinin replikasyonu okumaları standart veritabanı sorgu logları için görünmez - sorgulardan ziyade bir replikasyon protokolü kullanırlar - bu nedenle onları tüketicinin gerekli korelasyon diski, ağ ve bağlantı düzeyinde kanıt olarak tanımlamak. Üçüncü olarak, ETL hizmeti kesintiye uğramak için inşa edilmiştir: İşlerini kullanmayı ve bağlantılarını her ikisine de devre dışı bırakmak, çünkü otomatik olarak saniyeler içinde yeniden bağlantı kurar ve diğerlerini yeniden başlatırken başka bir işe yeniden başlar. Sadece bilgilerini iptal etmek bunu durdurdu. # ##Değiştiğimiz şey **Tuning WMS yanıt-zaman uyarı eşleri.** Bu olayın arkasındaki durum bir gecede yedi saat boyunca mevcuttu, ancak ışık altında uyarı eşlerimizi geçmek için yanıt süreleri çok az sürdü - bu yüzden ilk uyarı sadece bir kez depo aktivitesi yükseldi ve müşteriler zaten etkilendi. Bu eşleri, düşük yük de dahil olmak üzere WMS yanıt zamanında daha küçük değişikliklere karşı hassas hale getiriyoruz, bu yüzden bu gibi olaylar yakalanmış ve müşterilere ulaşmadan önce harekete geçti. Bu, bu olayın belirli önde gelen göstergeleri hakkında uyarı içerir - disk bant genişliği tüketimi ve disk kuyruk derinliği. ** Veritabanı, büyük ölçüde daha fazla disk bant genişliği ile bir örnek türüne göç edildi **, bu tür bir artışları absorbe etmek için üst düzey talep üzerine önemli bir oda vermek. ** ETL satıcısı ile soruşturmamızı sürdürüyoruz.** Aynı anda iş yeniden başlatması için bir açıklama arayan onlarla açık bir davamız var ve müşteri kaynaklarına karşı yeniden hazırlanmak için oran sınırlamak ve tutarlılık kapakları gerektiriyoruz. Bu çalışma devam ediyor.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 20 Ağustos 2026 14:06 UTCinvestigating

   TMS WebPortal'ın bazı müşteriler için yüklemediği veya başarısız olduğuna dair raporlar aldık. Sorunu aktif olarak araştırıyoruz ve daha fazla bilgi mevcut olacak.

2. 20 Ağustos 2026 15:02 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

3. 20 Ağustos 2026 15:16 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

4. 20 Ağustos 2026 18:06 UTCresolved

   Bu olay çözüldü.

5. 20 Ağustos 2026 19:35 UTCpostmortem

   # Post-Incident Report: Elevated API and Login Errors - August 20, 2026 **Status:** Resolved **Incident window:** August 20, 2026, 06:31 - 08:11 PDT \(13:31 - 15:11 UTC\) **Affected:** ShipHawk API and dashboard requests in shared production environments, plus the login service. Impact was partial rather than a complete outage: approximately 25% of overall API traffic on [shiphawk.com](http://shiphawk.com) failed during its affected window; failure rates within affected environments ranged from approximately 37% to 48%, and approximately 41% of login-service requests failed. **Not affected:** In-Cart rating \(and all /api/v4/rates requests\), background processing \(all scheduled jobs, write backs, webhooks, async label generation, tracking and carrier communications ran normally\), data integrity. ## Summary On the morning of August 20, an operating-system critical security update published by Ubuntu - and applied automatically by our standard patching process - contained a defect in the web server component \(nginx\) that sits in front of the ShipHawk application. The affected package was published on August 19 as [USN-8563-3](https://ubuntu.com/security/notices/USN-8563-3). Ubuntu confirmed that this update introduced a regression and published [USN-8563-4](https://ubuntu.com/security/notices/USN-8563-4) the same day, reverting the problematic change pending further investigation. While the faulty version was running, the proxy layer corrupted the URL of many incoming requests before handing them to the application. The application could not match the corrupted URLs to any known endpoint and answered **404 Not Found**. The failures were immediate, clean rejections: no request was partially processed, routed to the wrong account, or lost after acceptance. Our servers do not all download and install operating-system security updates at the same moment; update checks and installation windows are staggered across hosts. As a result, some servers downloaded the faulty nginx build before Ubuntu published the corrected package, while others checked later and downloaded the corrected build directly. Only the servers that had already downloaded the faulty package became affected when their scheduled installation ran. This is why the issue appeared intermittent: otherwise-identical requests could fail or succeed depending on which server handled them. Even on servers running the faulty nginx package, only a subset of requests failed. The regression affected specific nginx routing rules rather than the entire proxy configuration, so many URL patterns continued to work normally on an affected server. The incident was fully resolved by 08:11 PDT after every affected server was upgraded to the corrected package and verified healthy. No customer action was or is required. ## What was affected The numbers below count **only failures caused by this incident**. Ordinary 404 responses \(lookups of records that genuinely don't exist, invalid URLs, bot traffic\) were identified by their distinct response signature and excluded. | Environment | Scope | Impacted window \(PDT\) | Failed requests | | --- | --- | --- | --- | | sh-p-1 environment | 2 of 3 web servers | 06:34 - 08:08 | ≈37% of requests on affected servers; ≈25% of overall API traffic | | Login service | Both servers | 06:33 - 08:08 | ≈41% of login-service requests | | sh-p-2 environment | 2 of 3 web servers | 06:31 - 08:08 | ≈47% of requests on affected servers | | sh-p-3 environment | 2 of 3 web servers | 06:31 - 08:11 | ≈48% of requests on affected servers | ‌ What this looked like in practice: * **API integrations** received HTTP 404 responses for valid requests. Because failures were immediate and stateless, client retries could succeed when they landed on an unaffected server. * **Dashboard and login** pages failed to load or sign in intermittently. * Failures depended on the exact URL: some request types passed through unaffected even on faulty servers, adding to the intermittent appearance. ## What was NOT affected * **In-cart rating requests.** All rating requests from the web portal, e-commerce platforms, ERP platforms and regular API requests to `/api/v4/rates` were working as usual. * **Background jobs were not affected at all.** All asynchronous processing - scheduled jobs, write backs, inventory sync, webhook deliveries, document and label generation, carrier and ERP communications - runs behind the proxy layer and continued normally throughout the incident. No queued work was lost or delayed. * **Data integrity.** No data was lost, altered, or corrupted. Requests either completed normally or were rejected outright. * **Security and tenancy.** No request was routed to another account, and no security boundary was crossed. The corruption occurred after all access controls were applied. The underlying Ubuntu update was a preventive security patch; the vulnerability it addressed was not exploited on our systems. ## Timeline \(all times PDT, August 20, 2026\) * **Aug 19 \(daytime\)** - Ubuntu publishes a security update for nginx; a defect is reported, and Ubuntu publishes a corrected package the same day. The corrected version propagates to public update mirrors overnight. * **Aug 19, 18:24 - 23:09** - The nightly update checks on the later-affected servers download the day's nginx update. At these moments, the faulty build is still the newest available on the mirrors. This step only downloads the package; installation happens during the next morning's patch window. * **Aug 20, 04:12 - 05:05** - Another group of servers runs its nightly update check after the corrected build has reached the mirrors. These servers download the fixed version and remain healthy throughout the incident. * **~06:00** - A routine, unrelated application configuration update is applied for upcoming releases. It has no effect on currently released functionality and **plays no role in the incident**, but because it is the only known change that morning, it becomes the first suspect once errors appear. * **06:00** - The nightly automated patching window begins rolling nginx updates across environments. Some servers already have the corrected package downloaded, while others have the faulty package. * **06:31 - 06:34 - INCIDENT START.** As the rolling automated patch window progresses, the previously downloaded faulty nginx package is installed on multiple web and login servers across shared production environments. Because patch schedules are staggered, not all servers update at once, and some servers remain healthy. The first customer-facing failed requests begin at **06:31**. * **06:35** - Automated external monitoring alerts on elevated errors. **Investigation begins immediately.** * **06:36 - 07:15** - Engineers first investigate the ~06:00 configuration update, the only known application-level change with closely matching timing. It is ruled out, and attention turns to the web/proxy layer. * **06:52** - The rolling patch window continues and the faulty package is activated on additional servers. Impact increases as more affected servers restart onto the faulty nginx version, while servers that downloaded Ubuntu's corrected package remain healthy. * **06:55** - A remaining web server updates using Ubuntu's corrected package and stays healthy throughout, continuing to serve its share of traffic correctly. * **07:18 - 07:19** - Affected web servers are restarted as a mitigation attempt. This has no effect because the faulty nginx package remains installed. * **07:20 - 07:55** - Suspect servers are removed from load-balancer rotation. Symptoms persist because the login service and application environments are independently affected, which materially widens the search. * **07:41** - The URL-corruption pattern is identified in application logs. * **07:45 - 08:00** - Per-server testing isolates the faulty servers. The only difference from healthy servers is the nginx package version. The faulty build is matched to Ubuntu's published regression notice and corrected package. * **08:02 - 08:11** - The corrected package is installed across all affected servers. Error rates return to normal immediately on each server as it restarts onto the fixed version. The final affected environment returns to normal at **08:11 - INCIDENT FULLY RESOLVED**. * **08:11\+** - Full verification is completed: every server is individually tested, and API, dashboard, login, and production environments are confirmed healthy. ## Why resolution took ~95 minutes from alert Detection was fast, but three factors slowed diagnosis. First, a routine configuration change earlier that morning was the only known change in the environment and had to be ruled out - automated OS patching does not appear in any application-level change log. Second, the failure was intermittent by nature: unaffected servers continued serving normally, and even affected servers successfully handled request types whose routing rules were not impacted. Third, removing the suspect servers from rotation did not stop the errors - because other tiers were independently affected - which initially pointed the investigation away from those servers. ## What we are changing **1. Stage operating-system security patches before production.** Automated OS- and nginx-level security updates, including critical patches, will first be installed on non-production servers. Automated application-level validation will exercise representative API, dashboard, and login paths against the updated servers before the same package versions are allowed to roll into production. Production rollout will begin only after those checks pass. **2. Faster version-level diagnosis.** Our incident runbooks now include immediate comparison of package versions and restart history across servers whenever identically-configured servers behave differently.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

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

   Resolved by FedEx

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

   This incident has been resolved.

1. 18 Mayıs 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 Mayıs 2026 21:43 UTCresolved

   Resolved by PrintNode.

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

   Resolved by FedEx.

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

   The AWS issue affecting carriers has been resolved.

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

   Resolved by USPS Endicia

1. 29 Eylül 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 Eylül 2025 22:40 UTCresolved

   Confirmed as resolved by WWEX.

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

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

4. 21 Haziran 2025 04:07 UTCresolved

   This incident has been resolved.

1. 5 Mayıs 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 Mayıs 2025 23:10 UTCresolved

   This incident has been resolved.

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

   This incident has been resolved.

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

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

3. 11 Mart 2025 22:34 UTCresolved

   This incident has been resolved.

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

   Resolved by Pitney Bowes

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

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

3. 26 Temmuz 2024 00:14 UTCresolved

   This incident has been resolved.

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

   Resolved by Endicia.

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

   Resolved by FedEx.

1. 22 Mayıs 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 Mayıs 2024 20:20 UTCresolved

   Resolved by FedEx team.

1. 17 Mayıs 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 Mayıs 2024 22:41 UTCresolved

   Resolved by UPS.