FedEx Web 服务退化
Pending
受影响的组件
FedEx Web Services
- monitoring
FedEx网络服务目前性能正在退化,一些客户已报告有问题预订FedEx货运. 在联邦快递公司努力解决这一问题的同时,我们将继续监测局势。 目前FedEx响应时间请访问:https://www.shipppingapimonitor.com/history.html?api=fedex
- resolved
联邦快递方面解决了.
自动翻译自官方事件更新。
55 Shiphawk incidents · 2021年2月 — official updates, affected components, duration and resolution details.
FedEx网络服务目前性能正在退化,一些客户已报告有问题预订FedEx货运. 在联邦快递公司努力解决这一问题的同时,我们将继续监测局势。 目前FedEx响应时间请访问:https://www.shipppingapimonitor.com/history.html?api=fedex
联邦快递方面解决了.
自动翻译自官方事件更新。
一些客户在WMS访问方面出现缓慢. 我们的小组正在积极调查这个问题.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决。 详细情况一经公布,我们将立即分享.
□ 事故后报告:一个数据库的仓库缓慢和出错 -- -- 2026年8月25日 ** 现状:** 决定 ** 事件窗口:** 2026年8月25日~04:30-08:45 PDT\(07:30-11:45 ET\) ** 受影响的:** 客户数据库被托管在我们美国东部仓库组的一个WMS数据库实例上:页面负荷时间高达20x正常,扫描器和管理员屏幕在最糟糕的时期间歇出错。 ** 未受影响:** 所有其他 WMS 数据库实例和仓库组, TMS 平台, 数据完整性\ (没有丢失、 重复或部分应用\), 所有已完成的工作 - 每一个被接受的交易都被正确处理 。 你受影响了吗? 影响仅限于客户,他们的WMS数据库设在我们美国东部仓库集团的一个具体数据库实例上,而且只在8月25日上午(大约04:30-08:45 PDT/07:30-11:45 ET\)进行。 如果您在窗口期间没有看到 WMS 中缓慢的页面负载, 您的环境没有涉及 。 所有其他WMS数据库实例和仓库组以及整个TMS平台在整个过程中正常运行。 页:1 8月24日晚,一个第三方ETL服务将ShipHawk的数据复制到我们的数据仓库中,它立即针对我们的一个生产数据库重新启动了一大批同步工作。 每一个重启的工作开始以全速,并行,不限制任何速率的方式再读积压的历史变化数据. 阅读量攀升到预期高峰的五倍左右,消耗了该数据库实例可用的大部分磁盘带宽。 这在一夜之间开始,当仓库活动轻而易举时,因此对当时的业务没有影响. 8月25日美东早班开通后,在已经饱和的信道上方增加了正常的WMS活性,实例达到了其带宽限制. 从应用程序的角度来看,这作为缓慢的数据库答复出现:通常以毫秒的速度返回的查询需要更长的时间,工作排到后面,并缓慢地加载页面。 在数据库回复超过应用程序超时时,页面返回错误而不是加载. 整个服务一直运作。 在整个受影响案例中,客户处理了该窗口通常处理的总量的70%左右(抽取、包装和库存移动),尽管经验缓慢,有时难以与之合作,而且影响程度因客户而异。 情况通过完全在08:37取消ETL服务数据库证书而得到解决. 数据库在8分钟内恢复. 在接下来的两小时内,工作被拖延了,所有受影响的仓库都恢复了正常速度。 没有要求客户采取行动,也没有影响数据。 没有损失、重复或部分应用任何交易 -- -- 我们对照覆盖整个事件窗口的集成记录核实了这一点。 在作出任何修改之前,提交的工作要么完成得正确,要么失败。 下文将对此作更详尽的说明。 影响是什么? 影响仅限于客户,其数据库设在美国东部仓库集团受影响的WMS数据库实例上。 在整个事件窗口中,系统全方位缓慢 -- -- 扫描器和管理员页通常在第二层下装入,需要多多倍时间 -- -- 在数据库回复超过应用程序超时时,页面返回错误而不是加载。 这在实际中是什么样子: ** Warehouse 楼层:** 扫描页\(挑取、移动、调整存货\) 装入速度非常慢;在一页被卡住时重试的工人可以收到一页出错,必须回去重复操作。 ** 错误集中在一次爆炸中,而不是在整个事件中。 ** 大部分在拥堵高峰期倒入了一扇15分钟的窗口\(06:15-06:30 PDT\). 在计算我们网络服务器和应用程序日志中确认的错误页时,受影响最大的仓库看到该窗口有71个。 ** 整个系统保持不变。 ** 每一份提交的交易要么完成得正确,要么在作出任何修改之前完全失败。 在最深的减速窗口中,我们可以为继续工作的用户显示成百上千个交易成功完成. QQ 未受影响 ** 数据完整性。 ** 错误发生在处理请求的一开始就,在作出任何更改之前。 没有丢失、重复或部分应用交易。 每一次完成的完成, 库存移动和运出 都是正确的 -- 我们核实了事件窗口的集成记录。 ** 订购和向企业资源规划系统和市场运送同步** 在整个过程中完成得正确;在减缓过程中排队的张贴在追赶过程中全部交付\ (在整合日志中核实 - 没有失败的张贴\)。 ** 所有其它环境。 ** 我们其他数据库的仓库和整个TMS平台正常运行。 ** 安全和租赁。 ** 任何一点都没有涉及安全边界。 所涉第三方服务是一个数据整合供应商,以我们颁发的证书运作;问题在于其阅读量,而不是任何未经授权的访问。 QQ 时间线\( 全部为 PDT; 为 ET\ 添加3小时) 时间 时间 活动 | -- -- -- -- -- -- -- QQ Aug 24, 22: 54 - 22: 57 QQ ETL服务在三分钟窗口内重新启动~22同步任务与数据库对接. 每个人开始全速重读历史变化数据。 8月24日 22:54 - 23:50 读取量攀升到约5倍的预期峰值,消耗了大部分实例可用的磁盘带宽. 过夜的仓库流量很小,所以还没有客户可见的效果。 8月25日~04:30 美东仓库早班开通. 合并需求超过被封顶的网络速度; 队列开始构建并开始首页渲染比正常慢. QQ ^ 05:30 ^ 自动响应-时间监测警报作为仓库活动坡道;同时期客户报告缓慢到达. 调查开始 ^ 06:00 - 07:00 ^ 峰值拥堵:数据库连接突起至~15x正常,因为请求堆积而成;扫描屏出错的浪潮会出来\(06:15-0:30\). | ^ 06:50 根因被识别:磁盘带宽超过实例限制;销售商的复制流被识别为驱动. ^ ○○○○○○○○○○○○○ QQ 07:20 - 08:30 ETL服务同步任务在其控制台被波浪暂停并结束其数据库会话;服务在每次数秒内自动重接并持续阅读. 在此期间,它开始增加工作。 | QQ 08:35 QQ ETL服务数据库证书被锁定,其会话结束最后一次. \ 08:38 - 08:45 数据库队列排出;页面响应时间恢复正常. 客户撞击结束。 ###为什么从第一次报告起就解决了~3小时 有三个因素延长了时限。 首先,触发发生在症状发生前7小时. ETL服务的重读在一夜之间运行,已经消耗了可用的带宽,但是在那个时间,由于仓库活动灯光的限制,系统响应时间只产生了微小的变化——低于我们的警戒阈值——所以它没有被探测出. 我们的自动监测在仓库活动在上午升级时确实发出警报,但到那时,基本变化已经存在了7小时,而且最近没有部署或配置变化。 其次,ETL服务的复制读取是标准数据库查询日志所看不见的——它们使用复制协议而不是查询——从而确定它们为消费者所需的关联磁盘、网络和连接级证据。 第三,ETL服务是为了在中断中生存而建造的:由于在几秒内自动重接而导致中断工作并终止其连接,两者都以缓解方式失败了,在我们失去他人时它重新启动了额外的工作. 只是吊销了它的证书才阻止了它。 我们正在改变 ** WMS 响应时间警报阈值。 ** 这起事件背后的状况持续了7个小时, 但轻载下, 我们正在调整这些阈值,以便对WMS响应时间的更小的班次敏感,包括低载时,所以这样的事件在到达客户之前被抓住并采取行动. 这包括提醒本次事件的具体主要指标——磁盘带宽消耗和磁盘队列深度. ** 数据库已迁移到磁盘带宽大得多的实例类型,使顶部空间大大高于吸收这种尖锐需求。 ** 我们正在继续同ETL供应商进行调查。 ** 我们有一个公开的案件,他们要求对同时重新开始工作作出解释,并且要求对客户来源进行再读要求费率限制和货币上限。 这项工作正在进行中.
自动翻译自官方事件更新。
我们收到消息称 TMS WebPortal 正在返回错误或无法为一些客户加载. 我们正在积极调查这个问题,并将在获得更多信息后提供最新资料.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
# 事件后报告: API和登录错误 - 2026年8月20日 ** 现状:** 决定 ** 事件窗口:** 2026年8月20日,06:31 - 08:11 PDT\(13:31 - 15:11 UTC\) ** 受到影响:** ShipHawk API和共享生产环境中的仪表板请求,加上登录服务。 影响是局部的,而不是完全的停用:在[shippawk.com](http://shippawk.com)上,大约25%的API流量在受影响的窗口内失败;受影响环境中的故障率从大约37%到48%不等,大约41%的登录服务请求失败. **未受影响:** In-Cart 评分\ (和所有/api/v4/rates 请求\),背景处理\\ (所有预定任务,回写,网呼,async标签生成,跟踪和载体通信正常运行\),数据完整性. □ 总结 8月20日上午,由Ubuntu发布的操作系统关键安全更新——通过我们的标准补丁程序自动应用——包含了坐在ShipHawk应用程序前的网页服务器组件\(nginx\)中的一个缺陷. 受影响的套装于8月19日被公布为[USN-8563-3] (https://ubuntu.com/security/notices/USN-8563-3). Ubuntu确认这一更新引入了回归,并于同日发表[USN-8563-4](https://ubuntu.com/security/notices/USN-8563-4),恢复了问题变化,等待进一步调查. 在错误的版本运行时,代理层在将许多收到的请求交给应用程序之前会损坏其URL. 应用程序无法将已损坏的 URL 匹配到任何已知的端点并回答 ** 404 Not Found**. 失败是立即的、干净的拒绝:没有部分处理请求,没有转到错误的账户,也没有在接受后丢失。 我们的服务器不同时下载和安装操作系统安全更新;更新检查和安装窗口在主机之间交错. 因此,有的服务器在Ubuntu发布已更正的软件包之前下载了错误的nginx构建,而有的服务器在稍后检查后直接下载了已更正的构建. 只有已经下载出错的软件包的服务器在预定安装运行时受到影响. 正因为如此,这个问题显得断断续续:否则相同的请求可能失败或成功,取决于哪个服务器处理了这些请求. 即使在运行错误的 nginx 软件包的服务器上,也只有一个子集请求失败了. 回归影响了特定的 nginx 路由规则, 而不是整个代理配置, 因此许多 URL 模式在受影响的服务器上继续正常工作 。 事件以08:11PDT完全解决了,因为每个受到影响的服务器都升级为被更正的包并被证实健康. 没有或不需要客户采取行动。 □ 所受影响 以下数字只计算这一事件造成的故障**。 普通的404个响应\ (查找真正不存在的记录, 无效的 URL , bot 流量\) 被其显著的响应签名所识别并排除 。 环境 环境 环境 环境 环境 | -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- * 3个网络服务器中的2个 QQ 登录服务 QQ 两个服务器 06:33 - 08:08 QQ 41% 登录服务请求 QQ 6:31 - 08:08 QQ 47%的请求在受影响的服务器上 QQ 3个网络服务器中的2个 这在实际中是什么样子: * ** API集成** 收到HTTP 404对有效请求的答复。 由于失败是即时的和无国籍的,当客户端降落在未受影响的服务器上时,客户端的再试可能成功. * ** Dashboard和登录**页间歇地加载或签名失败. * 失败取决于准确的URL:一些请求类型通过,甚至不受影响于有缺陷的服务器,增加了间歇外观. ∮什么没有受到影响∮ * ** 货物定级请求。 ** 门户网站、电子商务平台、企业资源规划平台和定期API对`/api/v4/rates'的评级请求都照常有效。 * 背景工作根本没有受到影响。 ** 所有同步处理 -- -- 预定任务、回写、库存同步、网络存储交付、文件和标签生成、载体和企业资源规划系统通信 -- -- 都在代理层后行并在整个事件中正常持续。 没有队列中的工作丢失或延迟 。 * 数据完整性。 ** 没有数据丢失、被篡改或损坏。 请求要么正常完成,要么被彻底驳回。 * 安全和租赁。 ** 没有向另一个账户提出请求,也没有越过安全边界。 腐败发生在所有出入控制实施之后。 Ubuntu的更新是一个预防性安全补丁;它所处理的弱点在我们系统中没有得到利用。 ^ 时间线\ (所有时间PDT,2026年8月20日\). *** 8月19日\(日)** - Ubuntu发布nginx的安全更新;报告有缺陷,Ubuntu在同一天发布更正的软件包. 校正版在一夜之间向公众传播了更新镜. *** 8月19日,18:24 - 23:09** - 晚间受影响的服务器下载当天nginx更新的夜间更新检查. 此时,出错的建筑仍然是镜上最新的出错. 这一步骤只下载了软件包;安装发生在第二天早上的补丁窗口. ***8月20日,04:12 - 05:05** - 另一组服务器在被更正的构建到达镜像后进行其夜间更新检查. 这些服务器下载了固定版本,在整个事件中保持健康. * QQ06:00** - 对即将发布的版本应用常规的,无关的应用程序配置更新. 它对目前发布的功能没有影响,**在事件中没有扮演任何角色**,但由于它是当天早晨已知的唯一变化,一旦出错就成为了第一个疑犯. * ** 06:00 ** - 夜间自动补丁窗口开始跨环境滚动nginx更新. 有的服务器已经下载了被更正的软件包,有的服务器则有错误的软件包. * ** 06:31 - 06:34 - 紧急裁武条约。 ** 随着滚动自动补丁窗口的进步,之前下载的有缺陷的nginx包被安装在多个网络和登录服务器上,跨越共享的生产环境. 因为补丁时间表是错开的,并不是所有的服务器一次更新,有些服务器保持健康. 首个针对客户的失败请求开始于**06:31**. * ** 06:35** -- -- 关于高误差的自动外部监测警报。 ** 立即开始调查。 ** * **06:36 - 07:15 ** - 工程师们首先调查了~06:00配置更新,这是唯一已知的应用级别变化,与时间紧密匹配. 它被排除,注意力转向了网络/代用层. * **06:52** - 滚动补丁窗口继续,故障包被激活在额外的服务器上. 随着更多受影响的服务器重启到错误的 nginx 版本上,而下载了 Ubuntu 修正的软件包的服务器仍然保持健康,影响会增加. * **06:55** - 使用Ubuntu纠正后软件包的剩余网络服务器更新,并在整个过程中保持健康,继续正确服务其流量份额. * ** 07:18 - 07:19** - 受影响的网络服务器作为缓解努力重新启动。 这没有任何效果,因为错误的nginx包仍然被安装. * **07:20 - 07:55** - 疑似服务器从负载-平衡器旋转中移除. 症状持续存在,因为登录服务和应用环境受到独立影响,这在实质上扩大了搜索范围. * ** 07:41** - URL-腐败模式在应用程序日志中被识别出. ***07:45-08:00**-per-server测试隔离故障服务器. 与健康服务器的唯一区别是nginx包版本. 出错的构造与Ubuntu公布的回归通知和纠正后包相匹配. * ** 08:02-08:11** -- -- 在所有受影响的服务器上安装了更正后的软件包。 当每个服务器重新启动到固定版本时,错误率立即恢复到正常状态 。 最终受影响的环境于**08:11恢复正常 -- -- 事件完全恢复**。 * **08:11+- 完成全面核实:每个服务器都经过单独测试,API、仪表板、登录和生产环境得到确认。 □为什么解答从警戒到95分钟 检测速度快,但有三个因素减缓了诊断速度。 首先,当天早晨早些时候例行的配置变化是已知环境的唯一变化,必须排除 - 自动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.