83 Mews incidents · 2026年2月 — official updates, affected components, duration and resolution details.
自10月27日15:34CET起,Mews业务的来宾信使显示“正在建立客串通讯”,而不是许多已经使用该信箱的收件箱。 受影响地产的工作人员无法阅读或回复来宾留言, Mews操作的其他地方没有受到影响。 我们正调查原因.
自10月27日15:34起, 来宾信使(Guest Messenter)展出「正在建立嘉宾讯息」, 我们找到原因了 正在解决 你不需要做任何事情.
这一问题已经确定,一个解决办法正在实施之中.
缪斯小组查明了这一问题并正在拟订一项决议。 随着我们取得进展,将进一步提供最新情况.
来宾信使为所有财产正常工作.
这一问题现已得到全面解决。 Mews现在已按预期运作.
自动翻译自官方事件更新。
该小组已解决这一问题,我们正在密切监测这一制度,以确保稳定.
这一问题现已得到全面解决。 Mews现在已按预期运作.
自动翻译自官方事件更新。
我们正在调查一个问题,向Booking.com提供最新库存。 所有请求都排队,并等待我们一方预订.com接受. 一旦问题得到解决,我们将推动所有排队数据.
我们确定原因在Booking.com方面。 我们正在与他们接触,以尽快解决这一问题。 保留仍在出现,这一问题只影响到发送清单更新(即提供、价格和限制).
Booking.com 积极致力于解决问题. 这被归类为严重干扰他们的服务。 该事件可在此观测-https://connection-status.booking.com/. 不幸的是,这个问题也已开始影响保留的提出,因此我们可以确认,没有提出保留。 因此,我们决定将事件重新定性为严重事件。 一旦这个问题在Booking.com方面得到解决,我们将处理收回保留,以及丢失的库存更新.
关于"定"的一期. com一方仍未解决,库存更新和预订交付仍然受到影响. 我们正在继续监测局势并准备恢复进程,以便一旦Booking.com恢复服务,我们就可以开始处理排队的库存更新并恢复受影响的保留。 一旦取得有意义的进展,我们将再次提供最新情况.
Booking.com解决了这个问题!. 我们正注视着库存更新的恢复过程。 在协调世界时11:00至协调世界时15:00之间创建的更改被延迟交付至预订.com. 我们还可以确认,我们看到来自Booking.com的保留意见。 我们期望Booking.com在停用间隔期间将所有预定(创建或修改)寄给我们. 我们还在监测复苏进程
自动翻译自官方事件更新。
亲爱的顾客 我们知道有报道说,新披露的临界(零天)脆弱性影响到PHP 5.4+。 安全小组正在积极监测局势。 我们在做什么? 我们正评估我们的环境, 我们已部署更多监测和检测工具, 我们正密切关注PHP维护者及安全研究者的指导, 这对你意味着什么? 现在,你不需要采取任何行动。 保护你的数据并保持我们的服务是我们的首要任务, 随着形势的发展,我们将进一步分享最新情况。 有问题请联系支援组 谢谢你继续信任我.
我们正在继续应对最近披露的PHP中的关键弱点. PHP维护者现在已经发布了安全修饰,我们的团队正在审查这些修饰并准备安全推出. 我们还增加了保护措施,以减少接触, 而这项工作正在进行中, 我们正在密切监视我们的系统。 迄今为止,我们没有发现任何证据表明客户数据或Mews服务受到影响。 这对你意味着什么? 你不必做任何事情 在这个时候。 如果情况有变化,我们直接联系你 我们会发布另一个更新 随着我们的工作进展或 如果有什么变化。 有问题请联系支援组.
最近PHP弱点的更新安全套件开始可用。 我们准备在经过测试后 把它们应用到我们环境中受影响的地方 我们的保护措施保持原地不动,我们密切监测我们的系统. 目前尚未发现客户数据或Mews服务受到影响的证据. 你不必做任何事情 在这个时候。 修复工程启动后再发布最新消息.
为了应对今天宣布的PHP关键脆弱性,所有可能受到影响的事例都得到了弥补。 我们继续认真监测局势。 没有观察到客户受到影响。 谢谢你的理解.
自动翻译自官方事件更新。
我们注意到,该系统的性能已经降低。 我们目前正在调查。 谢谢你的耐心.
电子邮件发送已经恢复,并且从大约21:20 CEST开始正常运行. 已发送了积压的电子邮件。 原因是处理电子邮件队列的服务放缓。 我们已经恢复了全部能力,并正在密切监测,以证实这种能力仍然稳定.
在协调世界时约16:50至19:20之间,从Mews发送的电子邮件被延迟了45分钟. 这影响到所有电子邮件类型,包括两要素认证和签名电子邮件、预订确认、发票和来宾通信。 因此,一些用户在此期间无法向Mews签约. 原因是处理电子邮件队列的背景服务逐渐放缓。 我们于协调世界时19:20恢复了全部处理能力,之后发送了被拖延的电子邮件并恢复正常发送。 自那时起,我们一直在监测这项服务,并证实它保持稳定。 我们为中断道歉.
自动翻译自官方事件更新。
我们意识到会计分类账数据被拖延处理。 因此,会计分类账可能不显示最新的交易,生成的试算表可能比通常需要更长的时间才能产生. 没有丢失数据 。 所有待处理的会计事项一旦得到处理,将列入分类账。 我们的团队正在寻找解决方案, 我们为不便而道歉.
这个问题已经解决了。 所有会计分类账数据都已处理完毕,所有财产的会计分类账现已更新。 所有尚待处理的试算表都已产生,并正在毫不拖延地产生新的试算表。 没有丢失数据 。 我们为不便而道歉,并感谢你的耐心.
自动翻译自官方事件更新。
Mews团队发现了一个问题 与特定属性的切克热流, 我们正在研究一个解决方案。 随着我们取得进展,将进一步提供最新情况.
这个问题现在已经解决了,一些属性在Mews检查来宾或修改保留时反应缓慢并出错. 这包括更改日期、增加产品、取消和锁定保留。 一些行动用了大约30秒,然后失败了. 预订和检查客人没有受到影响。 我们很抱歉你前台被打乱了 我们回顾一下所发生的事情.
自动翻译自官方事件更新。
自协调世界时11:30左右起,从Booking.com开始的新预定,修改和取消没有到达Mews. 这是因停业而起 com的预留API,Booking.com在其连接状态页面上确认. 从Mews到Booking.com的其他频道和更新(可用性,费率和限制)不受影响. 保留没有丢失。 Booking.com将在服务恢复后再发售,并将自动在Mews创建. 在此之前,请检查access-date=中的日期值 (帮助) Booking.com外出网换新订房 避免超订. Booking.com恢复服务后.
Booking. 一些预定时间在协调世界时12:45至12:50之间,但大多数自协调世界时11:15起新订,修改和取消的预订仍然被推迟. 保留没有丢失。 一旦连接再次稳定,它们就会在Mews中被自动创建. 在此之前,请继续检查"Booking.com"外联网新订账,以避免超订. 我们正密切监视.
Booking. 自协调世界时11:15左右起,大多数新的,被修改和被取消的Booking.com的预订没有到达Mews;只有小批次间断地通过. 其他渠道不受影响。 保留没有丢失。 一旦预定,它们将在Mews自动创建。 com的服务是稳定的。 在此之前,请检查booking.com的外联网进行新的预订,并在需要时对可用性进行人工管理,以避免超订. 我们与Booking.com联系,并将在60分钟内再次发布最新消息.
校对:Soup 自协调世界时11:15左右起,大多数新的,经过修改并被取消的Booking.com保留地都没有到达Mews,而且自协调世界时13:42起也没有到达. Booking.com正在修复,但他们没有给出估计解析时间. 其他渠道不受影响。 保留没有丢失。 一旦预定,它们将在Mews自动创建。 com的服务是稳定的。 在此之前,请继续检查 Booking.com 外联网的新预订,并在需要时对可用性进行人工管理,以避免超订. 我们将在60分钟内再次发布最新消息.
Booking.com 保留地又开始到达Mews. 自协调世界时11:15起延迟的预订现在自动在Mews交付和创建. 这可能需要一些时间才能完成。 取订. com的服务还不能完全稳定,所以仍然有可能进一步拖延。 请继续检查booking.com的外联网,以了解最近的预订情况,直到这一事件得到解决. 我们将在60分钟内再次发布最新消息.
All Booking.com的预订在协调世界时11:15到协调世界时17:55之间被延迟,已交付给Mews,连接正常运行. 如果您仍然注意到缺少 Booking.com 的预定,请与 Booking.com 外联网进行比较,联系Mews Support.
自动翻译自官方事件更新。
意大利的客户无法在新帐单屏幕上的发票上加上扣除的税款。 我们已查明原因, 工作:在汉堡按钮上(计费屏幕上3个点) 切换到旧的Billing页面关闭账单,直到修复工作开始. 一旦修复完毕.
这一问题现已得到全面解决。 Mews现在已按预期运作。 将与受影响的客户联系,以便处理受影响的发票.
自动翻译自官方事件更新。
向频道管理者提供的可用性、价格和限制更新被推迟。 我们正在调查根源.
我们发现了拖延的问题。 导致更新速度放缓的累积更新被删除. 所有慢速更新将很快得到处理. 我们正在监测复苏情况.
延迟更新成功同步到频道管理器.
自动翻译自官方事件更新。
自协调世界时09:55起,Choice EDGE CRS和SynXis的一些保留地并未出现在Mews. 当保留包括新的忠诚成员时,就会出现这种情况。 我们找到了原因,我们的工程师正在修复它。 请检查archive-date=中的日期值 (帮助) 频道或 CRS 丢失预订. 修复后,我们将公布最新情况.
自协调世界时10月6日09:55左右起,一些以新忠诚成员身份入住草莓酒店的来宾的预订没有在Mews出现;没有产生新成员的预订正在正常处理. 我们正在努力解决, 受影响的财产应该检查他们的预订渠道.
在协调世界时10月6日约09:55至14:29之间,一些需要新的忠诚会籍的保留未能出现在Mews. 这影响到62个财产。 发行时间已固定,预订内容已重新处理. 请检查access-date=中的日期值 (帮助) 请检查access-date=中的日期值 (帮助) 请检查access-date=中的日期值 (帮助) 请检查access-date=中的日期值 (帮助).
自动翻译自官方事件更新。
我们知道有一群Flexkey客户 在Flexkey网站遇到问题 调查组已经查明了问题,目前正在部署一个热点的装置.
应恢复用于生产和服务的固定装置。 该小组正在监测恢复情况。 没有发生数据损失.
系统访问恢复.
自动翻译自官方事件更新。
我们知道,从Mews到一些发行渠道的可用性,速率和限制更新被延迟到一个子集属性. 从渠道到Mews的保留不受影响。 受影响的属性可能会看到更新比通常的更晚到达他们的频道. 更新不会丢失,一旦处理赶上就会交付.
我们已经查明了某些发行渠道延迟提供,速率和限制更新的原因. 单个连接系统的异常高的更新量正在减缓一个子集属性的处理队列. 库存排队情况正在恢复,延误正在减少。 受影响的属性会看到它们的更新随着积压清理而到达他们的渠道. 更新没有丢失 。 我们正在密切监视,一旦处理恢复正常,就会再次发布.
目前,Mews和分发渠道之间的保留处理和清单同步没有进展。 新的保留可能不出现在Mews中,可用性、速率和限制更新可能无法进入渠道。 无所失事,万事俱备,待问题解决后再处理
预订处理延迟了40分钟,现已全面运作。 所有延迟的预订都已处理完毕。 库存同步(可用性,速率和对频道的限制更新)仍然比平时慢,一些属性可能会出现延迟.
目前,Mews和配送渠道之间的预留处理和库存同步已经全面运作。 所有延迟的更新都已处理完毕.
自动翻译自官方事件更新。
2026年10月2日从15:14到15:41 CEST,Mews POS对所有客户来说都比较慢或无法使用. 客户无法登录到POS或完成交易。 我们的团队确定了原因,并在第一次警报后20分钟内扭转了配置变化. 15:41CEST服务全面恢复,运营不久后恢复正常.
** 问题** 2026年10月2日15:14 CEST,POS变得缓慢或对所有客户开放约27分钟. 客户无法登录或完成交易。 ** 行动** 团队查明了原因,并在第一次警报后20分钟内逆转了配置变化. 15:41CEST全面恢复服务,运营不久后恢复正常. ** 原因是** 收到的付款通知意外地增加,使POS数据库负荷过重,减速后中断服务. ** 解决** 配置变化被立即逆转以阻止通知洪灾. 我们现在正在改进通知处理器,以便在重新启用该功能前过滤出不相干的信息,并有一个分阶段的推出计划,其中包括在每个步骤上的数据库监测.
自动翻译自官方事件更新。
我们注意到,该系统的性能已经降低。 我们目前正在调查。 谢谢你的耐心.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们正在调查问题,为来宾信提供新的账户
提供了新的账户,功能正在发挥作用.
自动翻译自官方事件更新。
我们知道一个影响AI工具的问题. 原因是我们的人工智能供应商停电,瑞典地区也停电。 AI的动力特性可能是缓慢的,返回错误,或者无法使用. 核心Mews功能不受影响.
从第29天起
** 问题** 2026-09-29T14:30:06Z,Mews的AI-power功能——包括AI来宾留言,AI属性指南和智能任务建议——间歇地变得无法使用或退化. 造成这种情况的原因是,瑞典中部地区的Azure OpenAI和Azure AI的创始服务受到停工的影响,同时Anthropic的Claude服务也退化了。 核心Mews功能没有受到影响. ** 行动** 我们的团队迅速发现了这个问题,并证实由于上游断电,AI功能无法使用. 我们发布了一个状态页面更新以告知客户,整个下午监视情况,并在2026-09-29T19:06:00ZAzure服务恢复正常后确认完全恢复. ** 原因是** 中断的原因是微软Azure的基础设施问题影响到他们在瑞典中部地区的OpenAI和AI创始服务。 Azure报告说,负责管理请求元数据的后端服务在从依赖的数据库和缓存层读取时出现超时,导致该区域的客户间歇性故障并增加其延迟。 Anthropic的克洛德服务也同时出现退化. ** 解决** 这个问题由微软Azure公司在瑞典中部地区恢复了正常业务来解决. 在我们方面,我们正在努力增加产品内指标,以便在暂时没有AI的功能时,客户会清楚地了解,我们正在审查我们的集成点,以确保功能在恢复上游服务后自动恢复.
自动翻译自官方事件更新。
缪斯小组查明了这一问题并正在拟订一项决议。 这个问题影响到摩洛哥地区的大部分财产。 它阻止用户创建并修改新的保留. 为了防止这种情况发生,使用不同的浏览器,这些浏览器不会像边缘/色调一样被更新.
已经针对影响在摩洛哥地区设立和修改财产保留地的问题制订了一个固定办法。 现在应解决这一问题并恢复正常功能。 补救后无需采取进一步行动.
# 摩洛哥财产无法创建保留地# (2026年9月28日) # 发生了什么事# 2026年9月28日,在摩洛哥,我们大多数房产的工作人员和与他们一起在线预订的来宾在创建或更改预订时看到错误。 定价和可用性无法加载,因此新的预订无法完成. ∮为什么发生∮ 摩洛哥于2026年9月20日迁入永久的UTC\+0时区. Web浏览器和设备在不同的时间收到了这种更改,但是我们的服务器所使用的时区数据没有更新. 两人不同意每天何时开始,所以我们的系统拒绝了这些请求. ∮我们所做的∮ 问题一经报告,我们的工程队在约一小时内就查明了原因,并准备了定点补救. 它在协调世界时17:37开始直播,并在协调世界时17:58开始核实生产. 自那时起,保留、定价和供应通常有效。 在某些观点中,在受影响期间设定的保留时间可能会显示一个小时的休息时间。 我们的支援小组可以帮助任何问题。 □我们正在做的防止它 * 将我们的时区数据库升级为目前的版本,其中已经包括摩洛哥的改动。 * 监测这种错误,因此我们在一天之内就抓住它。 * 跟踪客户经营所在国即将发生的时区规则变化。 我们为这给你和你的客人造成的干扰而道歉.
自动翻译自官方事件更新。
我们注意到,该系统的性能已经降低。 我们目前正在调查。 谢谢你的耐心.
我们看到,该平台在所有连接上的性能已经恢复正常。 我们会继续监视事件.
我们查明了退化性能的来源,并采用了一种将其与系统其他部分隔离的缓解措施。 该系统现在应该正常地作出反应。 一些用户在生成"管理者报告"时可能仍然会经历缓慢. 我们继续调查并监测局势.
该系统继续正常运作,我们正在密切监测。 有些报告可能偶尔加载缓慢或未能加载,而我们则在进行永久固定.
缪斯小组查明了这一问题并正在拟订一项决议。 这个问题影响到摩洛哥地区的大部分财产。 它阻止用户创建并修改新的保留. 为了防止这种情况发生,使用不同的浏览器,这些浏览器不会像边缘/色调一样被更新. 注:这一更新是针对另一起事件,https://status.mews.com/incidents/jsp79g3qvh42, 并意外地张贴在这里。 为任何混淆道歉.
存在问题的报告仍然孤立为一个单独的部分,减少了其对系统其他部门的影响。 该平台正常运行,我们继续监测局势,同时努力寻求永久解决办法.
9月25日开始的在Mews造成缓慢和超时的问题已经得到解决. 所有受影响的财产现在都可以正常工作.
自动翻译自官方事件更新。
连接到 SynXis (Sabre) 的属性目前受到影响. 由于UTC大约04:20,可用性,速率和限制更新没有到达SynXis. 因为辛克西斯那边停电了 他们的服务正在拒绝我们的请求 我们和Sabre有联系 一旦SynXis可以到达,排队更新将自动重试. 未与 SynXis 连接的属性不受影响 。 下一次更新在60分钟.
连接到 SynXis (Sabre) 的属性仍然受到影响 。 范围比 我们之前说到的 自协调世界时约04:20起: - SynXis没有获得可用性、速率和限制更新。 - SynXis的新保留地没有到达Mews。 - 保留更新不同步返回 SynXis 。 SynXis仍然拒绝我们的请求。 错误水平从峰值下降,但 过去一小时来一直保持稳定,我们尚未看到任何复苏。 我们仍然 和Sabre联系 校正我们先前的更新: 并非所有已排队的更新都会自行重发 。 A级 部分在停用期间超过了自动重试的限制。 我们有 一旦SynXis可以到达,将自己重新处理它——不 您必须采取行动。 如果您使用 SynXis , 请继续将您的频道数据作为过时处理 。 直接检查新订的 SynXis 。 下一次更新在60分钟.
连接到 SynXis (Sabre) 的属性仍然受到影响 。 没有改变 我们上次更新中描述的影响,我们尚未看到复苏。 SynXis继续拒绝我们的请求。 错误水平没有比 过了两个小时 我们还在和Sabre联系,没有估计 时间从他们解决。 需要人工后处理的更新量继续增加,而 正在停电。 这意味着完全重同步需要一些时间 SynXis又可以接触到——可用性、费率和限制并非全部 当他们返回服务时,请立即改正。 我们会在这里确认什么时候 重同步完成 。 如果您使用 SynXis , 请继续将您的频道数据作为过时处理 。 直接检查新订的 SynXis 。 下一次更新在60分钟.
SynXis 从协调世界时08:40开始再次响应,并排队 更新正在处理中。 可得性、速率和限制更新,以及 保留同步, 又在流动 。 我们现在正在处理积压的工作。 超过自动更新 断电时的重试限制正由我们进行再处理——正在进行中 并需要一些时间。 您的频道数据可能仍然过时, 直至其过时 完成 。 一旦完成后处理和数据完全齐全,我们将在此确认 重新同步 。 下一次更新在60分钟.
我们发现与BWH的连接有更高的误差, UTC凌晨6点左右 更新仍在处理中,但有一部分正在 失败和重试, 因此一些更改可能会被延迟到达频道 。 这与辛西斯事件无关. 我们正在调查 下一次更新在60分钟.
SynXis已经完全回收,后处理完成. 所有更新 超过停用时的重试限制已经重新处理 。 重新同步提供、费率、限制和保留 SynXis连接属性. 无需采取进一步行动。 BWH 最佳西部CRS已经证实 他们一方有计划外的停电 导致 并且预定的维护费用会超过其窗口。 我们一直看到正常 BWH 连接自 UTC 大约 09: 10 起的错误级别和更新为 再次处理。 我们正在监测并等待他们确认 断电问题已完全解决。 下一次更新在60分钟之内, 或者如果有什么变化,更早.
此事已决. SynXis(Sabre)在协调世界时约04:20至08:40之间无法访问. BWH QQQ 最好的西方CRS 经历了一个单独的 计划外的停电 在他们一侧,由 在协调世界时6:00至09:10之间,维持其窗口超时。 这两条连接自此一直正常运行. 所有更新在 两种情况—— 可用性、比率、限制和保留—— 都存在。 重新处理和重新同步。 不需要你采取行动.
自动翻译自官方事件更新。
