Statuscast 中断历史

1. 2025年10月29日 UTC 16:04update

   在协调世界时10月29日15:45至协调世界时2025年10月30日00:05之间,客户和微软服务以Azure Front Door(AFD)为杠杆经历了晚报,超时和出错. AFD & CDN的提供服务仍然稳定,并按预期运行。 由于十分谨慎,所有通过门户或API到AFD的服务管理业务(包括创建,更新,删除和清洗)继续被暂时中止. 我们正在制定一项全面计划,以分阶段的方式逐步恢复这些计划,同时确保平台保持稳定。 随着我们取得进展,我们将继续定期交流最新情况。 下一次更新时间为协调世界时2025年10月31日01:00或更早.

2. 2025年10月31日 UTC 01:08update

   Azure Front Door (AFD)和内容交付网络(CDN)的交付数据平面在协调世界时2025年10月30日00:05全速缓解,并保持正常运行水平. 随着我们完成全面调查,进一步实施安全检查,服务管理业务(创建,更新,删除,清洗等)暂时无法实施. 一旦取消限制,我们将通知客户,我们将定期通报进展情况。 下一次更新将在协调世界时2025年10月31日19:00前进行,或视事件需要提前进行.

3. 2025年10月31日 UTC 20:03update

   Azure Front Door(AFD)和内容交付网络(CDN)的交付数据平面在协调世界时2025年10月30日00:05被完全缓解并保持正常运行水平. 随着我们完成全面调查,进一步实施安全检查,服务管理业务(创建,更新,删除,清洗等)暂时无法实施. 我们正努力提供一项关于何时可以解除限制的ETA,并将继续通过Azure Service Health定期通报进展情况。 下一次更新将在协调世界时2025年11月1日19:00之前,或者在事态需要时提前.

4. 2025年10月31日 UTC 21:35update

   Azure Front Door(AFD)和内容交付网络(CDN)的交付数据平面在协调世界时2025年10月30日00:05被完全缓解并保持正常运行水平. 随着我们完成全面调查,进一步实施安全检查,服务管理业务(创建,更新,删除,清洗等)暂时无法实施. 我们目前期望在2025年11月5日取消限制,我们将继续通过Azure Service Health定期通报进展情况。 下一次更新将在协调世界时2025年11月1日19:00之前,或者在事态需要时提前.

5. 2025年11月1日 UTC 19:41update

   Azure Front Door(AFD)和内容交付网络(CDN)的交付数据平面在协调世界时2025年10月30日00:05被完全缓解并保持正常运行水平. 随着我们完成全面调查,进一步实施安全检查,服务管理业务(创建,更新,删除,清洗等)暂时无法实施. 目前我们仍期望在2025年11月5日取消限制,我们将继续通过Azure Service Health定期通报进展情况。 下一次更新将在协调世界时2025年11月2日(UTC)下午7:00前进行,或者在事态需要时提前进行.

6. 2025年11月2日 UTC 20:31update

   Azure Front Door(AFD)和内容交付网络(CDN)的交付数据平面在协调世界时2025年10月30日00:05被完全缓解并保持正常运行水平. 随着我们完成全面调查,进一步实施安全检查,服务管理业务(创建,更新,删除,清洗等)暂时无法实施. 目前我们仍期望在2025年11月5日取消限制,我们将继续通过Azure Service Health定期通报进展情况。 下一次更新将在协调世界时2025年11月3日03:00前进行,或者在事态需要时提前进行.

7. 2025年11月2日 UTC 21:07update

   Azure Front Door(AFD)和内容交付网络(CDN)的交付数据平面在协调世界时2025年10月30日00:05被完全缓解并保持正常运行水平. 随着我们完成全面调查,进一步实施安全检查,服务管理业务(创建,更新,删除,清洗等)暂时无法实施. 目前我们仍期望在2025年11月5日取消限制,我们将继续通过Azure Service Health定期通报进展情况。 下一次更新将在协调世界时2025年11月3日03:00前进行,或者在事态需要时提前进行.

8. 2025年11月3日 UTC 03:02update

   Azure Front Door(AFD)和内容交付网络(CDN)的交付数据平面在协调世界时2025年10月30日00:05被完全缓解并保持正常运行水平. 随着我们完成全面调查,进一步实施安全检查,服务管理业务(创建,更新,删除,清洗等)暂时无法实施. 目前我们仍期望在2025年11月5日取消限制,我们将继续通过Azure Service Health定期通报进展情况。 下一次更新时间为协调世界时2025年11月3日19:00之前,或根据事态需要提前.

9. 2025年11月4日 UTC 00:14update

   Azure Front Door(AFD)和内容交付网络(CDN)的交付数据平面在协调世界时2025年10月30日00:05被完全缓解并保持正常运行水平. 作为完成全面调查和安全检查的一部分,暂时无法开展服务管理业务(创建、更新、删除、清洗等)。 现已取消对Azure订阅ID服务管理业务的限制。 请给30-40分钟左右的修改时间, 我们期望在2025年11月5日之前取消所有订阅限制,包括租户的其他订阅。 将通过Azure Service Health继续提供最新进展。 下一次更新将在协调世界时2025年11月4日22:00之前提供,或者在情况发生变化时提前提供.

10. 2025年11月4日 UTC 00:25update

    我们承认,以前的来文可能载有针对另一客户名单的信息。 我们对不便表示歉意,并请你注意以下情况。 Azure Front Door(AFD)和内容交付网络(CDN)的交付数据平面在协调世界时2025年10月30日00:05被完全缓解并保持正常运行水平. 随着我们完成全面调查,进一步实施安全检查,服务管理业务(创建,更新,删除,清洗等)暂时无法实施. 管理和旋转您自己的证书( BYOC) 证书的工作流程已经重新启用 。 我们将通过必要轮换的排队来监测工作进展情况。 我们将继续定期提供最新进展。 我们目前仍期望在2025年11月5日取消限制。 下一次更新时间为2025年11月4日协调世界时22:00之前,或根据事态需要提前.

11. 2025年11月4日 UTC 03:27update

    为了准备取消服务管理限制,发出了一份错误的信函,表示提前取消。 目前取消所有控制飞机限制的日期仍然是2025年11月5日。 下一次更新将在协调世界时2025年11月4日22:00之前提供,或者更早.

12. 2025年11月4日 UTC 22:22update

    Azure Front Door(AFD)和内容交付网络(CDN)的交付数据平面在协调世界时2025年10月30日00:05被完全缓解并保持正常运行水平. 随着我们完成全面调查,进一步实施安全检查,服务管理业务(创建,更新,删除,清洗等)暂时无法实施. 2025年11月5日,我们有望取消这一限制,但我们继续遭受到重大打击。 下一次更新将发出,以确认一旦发生这种情况,或如果情况需要,则更早.

13. 2025年11月5日 UTC 23:36update

    最新消息:自协调世界时11月5日23:00起,已取消2025年对Azure Front Door(AFD)和内容交付网络(CDN)服务管理业务的限制. 您现在可以在 AFD 服务管理机上恢复正常运行 。 为了加强安全和保护,我们已经将配置推广时间延长至45分钟。 目前正在进行的更多平台改进预计将进一步优化传播时间。 前情提要:Azure Front Door(AFD)和内容交付网络(CDN)的交付数据平面于2025年10月30日协调世界时00:05全面平面,并保持正常运行水平. 我们先前通知你,作为完成全面调查和安全检查的一部分,执行服务管理业务(创建、更新、删除、清洗等)暂时受到限制。 该通知旨在确认这些临时限制不再适用。 下一步: 正如我们的初步进度报告所提到,我们正在完成内部回顾,以便更详细地了解这一事件。 一旦这项工作完成,预计在大约7天之内,我们将发表我们最后的《事件后回顾》(PIR)——包括登记Azure事件回溯性活流的链接,讨论事件和我们的学习。 Azure Front Door 经常被问到的问题(FAQ) * * * 微软学习

14. 2025年11月5日 UTC 23:42resolved

    最新消息:自协调世界时11月5日23:00起,已取消2025年对Azure Front Door(AFD)和内容交付网络(CDN)服务管理业务的限制. 您现在可以在 AFD 服务管理机上恢复正常运行 。 为了加强安全和保护,我们已经将配置推广时间延长至45分钟。 目前正在进行的更多平台改进预计将进一步优化传播时间。 前情提要:Azure Front Door(AFD)和内容交付网络(CDN)的交付数据平面于2025年10月30日协调世界时00:05全面平面,并保持正常运行水平. 我们先前通知你,作为完成全面调查和安全检查的一部分,执行服务管理业务(创建、更新、删除、清洗等)暂时受到限制。 该通知旨在确认这些临时限制不再适用。 下一步: 正如我们的初步进度报告所提到,我们正在完成内部回顾,以便更详细地了解这一事件。 一旦这项工作完成,预计在大约7天之内,我们将发表我们最后的《事件后回顾》(PIR)——包括登记Azure事件回溯性活流的链接,讨论事件和我们的学习。 Azure Front Door 经常被问到的问题(FAQ) * * * 微软学习

自动翻译自官方事件更新。

1. 2025年10月29日 UTC 16:01update

   我们知道阿祖尔号全球停用。 我们的团队意识到这个问题。 状态网页和管理员门户可能无法访问。 我们为任何不便而道歉.

2. 2025年10月29日 UTC 18:17update

   微软Azure出道仍在影响域名,但不影响状态.page域. 您可以使用 https:// yourpagename.status.page 访问您的页面和管理员门户登录 。 我们为任何不便而道歉.

3. 2025年10月30日 UTC 05:40resolved

   服务现已开始运作。 这一事件已经得到解决.

自动翻译自官方事件更新。

1. 2025年4月4日 UTC 13:37update

   已提醒工程师注意通知处理的拖延。 我们目前正在调查,并将进一步详细采取后续行动.

2. 2025年4月4日 UTC 18:30resolved

   9:37 AM EDT发生一起事件,延误了事件通知的处理。 该事件于下午2: 30 EDT全面解决. 更多关于根源的细节将随之而来。 订阅者仍然会看到预期的状况页,但事件通知会被推迟.

自动翻译自官方事件更新。

1. 2025年2月27日 UTC 14:53update

   速取禅业. SANTA BARBARA, Calif., 2025年2月27日 – XurentTM,为现代企业和管理服务供应商专门建造的服务和运营管理平台,已经收购了尖端事件和警报管理解决方案的领跑者Zen Building. 这一收购标志着Xurent不断改革信息技术和重新界定各组织如何从头到尾处理重大事件的另一个重要里程碑。 Surrent的首席产品官Phil Christianson说道, “现在, 我们去年4月的“地位卡斯特”收购加强了我们的平台,大大提高了各组织传播重大事件细节的能力。 现在,随着Zen duct的收购,我们将使信息技术能够自动化和精简事件解决和根源补救,确保更快的纠正和防止再起事件。” 禅活是事故和警戒管理的创新者. 该平台已赢得声誉,使事件指挥官能够迅速将合适的小组聚集到虚拟的战争室、分门别类的问题和推动迅速解决。 通过将Zenduct与Xurrent强大的IT服务管理(ITSM)能力整合,客户将在一个单一的统一平台内享受全面的,端到端的IT业务和服务管理能力. 这种整合确保了在发生重大事件时,各组织不仅能够迅速管理和解决问题,而且能够采取有条理的办法来防止其再起。 Zenduct授权事件指挥官有效地协调反应小组,而Xurent的ITSM平台则确保任务分配给合适的小组,跟踪并及时完成,推动事件之间的持续改进. 通过将Zenduct与Xurrent的ITSM平台整合,各组织获得以下关键利益: • 实现虚拟作战室自动化,以迅速应对事件。 • 迅速管理和解决事件。 • 确保事故后补救任务完成的问责制。 “Zenduce的顶级事件和警报管理工具与Xurent的世界一流的IT服务管理的力量相结合,将使我们的客户能够以更现代、更连接、更自动化的方式充分控制他们的IT业务和服务管理,” “与Xurent一起,各小组应更快地采取行动,更快地解决事件,并确保这些事件不再发生——以高效、准确和全面负责的方式完成关键任务。” 关于Xurent XurentTM以AI动力自动化精简ITSM和IT操作管理. 我们的平台简化了工作流程,加强了协作,提高了生产率. 为可伸缩性而建造,Xurent无缝地适应了现代企业不断变化的需要,在最大限度地提高效率的同时将努力降到最低. 在www.xurrent.com上学习更多。 关于禅课 Zenduct是一款端到端事件和可调用的管理解决方案,通过电子邮件,电话,短信,Slack,和微软团队提供跨频道的提醒,以确保在服务停机期间及时通知你的团队. 为提高事件响应效率而设计,Zenculture提供一些功能,如可定制的提醒,可待命的时间安排,以及包含有超过150个工具的无缝集成,包括Datadog,Jira,和Slack. 使用禅克的组织报告说,情况有显著改善,包括停机时间缩短,平均承认时间(MTTA)和平均解决时间(MTTR)提高50%,以及节省费用。 详情请访问www.zenduct.com。 新闻稿:https://www.xurrent.com/press-release/xurrent-acquires-zenduct-complete-the-incident-response-and-refecutation-loop/ (中文(简体) )

2. 2025年2月27日 UTC 14:54resolved

   自动关闭

自动翻译自官方事件更新。

1. 2025年2月23日 UTC 14:00update

   身份认证工程师指出,一些加工退化可能导致某些行动的延误.

2. 2025年2月24日 UTC 02:00resolved

   小组已经查明了这个问题.

自动翻译自官方事件更新。

1. 2025年2月4日 UTC 22:30update

   StatusCast engineers noted a background processing degradation that caused delays in some actions from being completed in a timely fashion.

2. 2025年2月5日 UTC 02:00resolved

   This has been resolved. We apologize for any inconvenience.

1. 2024年12月29日 UTC 23:00update

   访问StateCast支持门户的域名已更新为https://xurrent-statuscast-portal.xurrent.com/. 虽然旧域将重定向到我们目前的域 我们建议适当更新你的书签.

2. 2024年12月29日 UTC 23:01resolved

   自动关闭

自动翻译自官方事件更新。

1. 2024年11月25日 UTC 19:24update

   StatusCast工程师在其背景处理中发现了一个备份,导致一些行动无法及时完成.

2. 2024年11月25日 UTC 20:32update

   工程师已经确定了处理中备份的根本原因. 在此期间,我们扩大了负责加快清理剩余物品的服务范围.

3. 2024年11月25日 UTC 22:06resolved

   各项服务应当按预期运作.

自动翻译自官方事件更新。

1. 2024年11月16日 UTC 01:00update

   已提醒StatusCast工程师注意可能影响性能的事件影响状态页和管理员应用响应时间. 这一事件不影响通知处理。 我们对这一不便表示歉意,并将很快提供最新情况.

2. 2024年11月18日 UTC 19:00resolved

   所有服务应充分运作并定期进行.

3. 2024年11月27日 UTC 20:00update

   StateCast的工程师确定,在2024年11月15日大约8:00PM EST,StateCast的几个应用服务器经历了一个问题,导致反应时间激增. StatusCast在Azure的基础设施旨在为在胁迫下提供的服务执行规模化程序,除了一项应用服务外,所有其他服务都成功地将服务恢复到可接受的业绩水平。 欧盟其余的应用服务没有正确规模,在退化状态下停留了多天. 11月18日,工程师被警告,一些客户仍在经历负载时间延迟,这时最后一个服务器被纠正. 事件发生后,StateCast的DevOps小组开始对所有缩放程序进行审计,以确保我们Azure业务地区的应用服务遵循一致的缩放程序,并确保将监测适当部署到所有服务机构,因为有一个单一的应用服务处于退化状态达数日之久是不可接受的.

自动翻译自官方事件更新。

1. 2024年9月5日 UTC 13:00update

   我们的团队很高兴宣布4米正式重命名为"Xurent". 我们新颖的外观和更新的身份,抓住了我们业务的实质,我们的平台,我们的愿景,以及它的价值. 我们的新外观正在一个新的网站、营销材料和Xurent应用程序中推出! 重要日期: • 9月5日(今天) • 新闻稿宣布了重新品牌的启动。 • 我们的新网站实况转播! 请查看www.xurrent.com。 • 9月7日 • 所有来自Xurent的通信将来自我们的新领域,www.xurrent.com。 这意味着电子邮件和任何其他官方通信。 这对你来说意味着什么? 从现在开始,你会看到我们的新品牌在电子邮件、网站和其他通信中出现。 请放心,这个变化不会影响您目前的服务。 感谢您成为Xurrent(原为4me)家族的重要成员. 虽然我们的外表在不断演变,但我们提供高质量产品和特殊客户支持的献身精神保持不变。 随着我们迈向充满活力和协作的未来,我们的使命和价值观继续推动着我们.

2. 2024年9月5日 UTC 13:01resolved

   自动关闭

自动翻译自官方事件更新。

1. 2024年8月1日 UTC 17:45update

   As of August 1st, 2024 we have removed the link to the Legacy Incident Editor from the admin portal to ensure that users maintain a unified experience and are able to take advantage of all of our latest improvements to the incident creation process.

2. 2024年8月1日 UTC 17:46resolved

   auto-closed

1. 2024年7月30日 UTC 13:30update

   早先曾提醒StatusCast工程师,有些用户遇到零星问题,试图连接到状态网页和管理员门户。 我们的主办商微软Azure通过他们的状态网页提醒我们,他们正在全球遇到一些网络问题。 一旦获得更多信息,我们将立即提供最新情况.

2. 2024年7月30日 UTC 14:44update

   查阅状况网页的情况保持稳定,Azure更新了状况,显示已参与故障处理程序,以改善其服务提供情况。 StatusCast的工程师们将继续密切关注此事,并在必要时发布更多更新.

3. 2024年7月30日 UTC 20:47update

   StateCast的申请继续保持稳定. 我们的工程师们将继续密切注视系统,因为微软还没有完全关闭他们身边的事件. 关于阿祖尔问题的更具体细节,请参考他们的状况页. 我们将根据需要提供更多的最新情况.

4. 2024年7月30日 UTC 22:00resolved

   微软已经关闭了他们一侧的发行,StateCast的平台继续按预期运行. 一旦微软公布了更多这方面的细节,我们将在此以RCA的形式提供.

5. 2024年8月1日 UTC 17:07update

   从微软: 缓解声明 - Azure Front Door 问题访问微软服务的子集 追踪编号:KTY1-HW8 发生了什么事? 在2024年7月30日协调世界时约11:45至19:43之间,一子集的客户可能曾遇到与全球微软服务子集相连接的问题. 受影响的服务包括Azure App Services,应用程序 Insights,Azure IoT Central,Azure Log搜索警报,Azure Policy,以及Azure门户网站本身和由微软365和微软Purview服务组成的子集. 我们目前知道什么? Azure Front Door(AFD)和Azure Content Network(CDN)组件的操作低于可接受的阈值,导致间歇性出错、超时和超时性。 虽然最初的触发事件是一次分布式的拒绝服务(DDoS)攻击,它激活了我们的DDoS保护机制,但初步调查表明,我们防守的实施出错会扩大攻击的影响而不是减轻. 我们怎么回应的? 在协调世界时11点45分开始对客户的撞击 我们开始调查 一旦了解使用量激增的性质,我们实施网络配置的改变,以支持我们的DDoS保护工作,并完成了替代网络路径的故障,以提供救济。 我们最初的网络配置变化在协调世界时14:10成功减轻了大部分影响. 一些客户报告可用率低于100%,我们于协调世界时18:00左右开始缓解。 我们采取了最新的缓解办法,首先在亚太地区和欧洲地区推广。 在证实这一订正办法成功地消除了最初缓解措施的副作用之后,我们将其推广到美洲地区。 在协调世界时19:43之前,故障率恢复到事故前水平——在监测交通和服务以确保问题得到全面缓解后,我们宣布事件缓解于协调世界时20:48. 一些下游服务需要更长的时间才能恢复,这取决于如何配置它们来使用AFD和/或CDN. 接下来会发生什么? 我们的小组将完成内部回顾,以便更详细地了解这一事件。 我们将在大约72小时内发表《事后事件初步审查》,以分享更多关于发生的事情和我们如何作出反应的细节。 在完成内部回顾之后,一般在14天内,我们将发表《事件最后回顾》,并附上任何补充细节和学习。 要在此事发生时得到通知,以及/或了解未来的Azure服务问题,请确保您配置并保持Azure服务健康提示 — — 这些提示可以触发电子邮件、短信、推出通知、网络呼号等:https://aka.ms/ash-aerts。 关于事后事件审查的更多信息,请参见https://aka.ms/AzurePIRs. 最后,关于为云事件做好准备的更广泛指导,参见https://aka.ms/incidentready.

自动翻译自官方事件更新。

1. 2024年7月22日 UTC 16:30update

   支持StateCast和4me的支援小组准备采取下一步行动,将我们的支援服务从StateCast的遗留罚单系统转移到直接使用4me来处理所有更改要求和事件。 下一步将StateCast的操作整合为4me, 最终会让您更深入地了解您提出的请求及其状况。 有什么变化? 2024年7月24日(星期三)StatusCast的支持门户将转移到https://4me-statuscast-portal. 这个新的门户会给您一个更准确的票价状况,如果您要求更改或遇到一个需要开发工作的问题,您将会在从开发到QA,到生产视角的状态中具有能见度. 此外,客户还可以通过一个包含知识库的门户,找到其问题的答案。 知识库将随着我们的发展而扩展。 我们非常兴奋地将这种广泛的可见度带给我们的顾客, 由于这一改变,电子邮件支持@statuscast.com将不再开票. 您需要访问自助门户网站以提交和访问支持请求。 已添加到 StateCast 的管理员门户中, 您可以通过选择 设置 & gt; 帮助中心 & gt; 支持 门票访问此自我服务门户 现有的StatusCast管理员获准进入这一新门户。 要访问StatusCast门户网站,请访问 https://xurrent-statuscast-portal.xurrent.com/ 并开始使用 “ 忘记你的4me 密码? ” (1) 这样您就可以收到电子邮件来注册您的支持门户密码 。 如果您在这样做时没有获得电子邮件, 您可能没有获准自动访问, 在这种情况下, 您可以点击“ 注册为新用户” (2) 自行注册 : 状态卡斯特门户网站要求您使用电子邮件地址并设置包含18个字符的密码.

2. 2024年7月22日 UTC 16:31resolved

   自动关闭

自动翻译自官方事件更新。

1. 2024年7月5日 UTC 13:00update

   为了履行我们对安全和透明度的承诺,我们想通知你,我们的短信供应商特维利奥已经提醒我们的安全小组注意已经发生的一起事件。 以下是我们从Twilio收到的声明,其中详细叙述了事件和已采取的行动: ————————————————————————————————. Twilio已经从我们的备用载体iBasis中得知, 识别Mobile无意中暴露了 iBasis 在互联网上公开发送的某些短信相关数据, 我们写信告知您,您的一些个人数据和非个人数据(如与营销运动有关的数据)被一个安全研究小组查取,而它被身份识别工具公开曝光。 虽然这起事件不在Twilio的控制范围之内,但我们非常认真对待,并致力于帮助你了解全部影响. 你该知道什么? 为了在特定区域发送信息,Twilio依靠许多承运人最大限度地向最终目的地交付信息。 Twilio被通知iBasis(一款Twilio备份载体)曾使用过IDMobile(iBasis的又一备份载体),后者在开发工作期间无意中允许在AWS S3 Bucket上公开访问. 本桶中包含的信息于2024年5月10-15日公开,于2024年5月13-14日之间查阅. 根据 " 识别机动 " 和 " 亚马逊AWS " 联合调查,我们得知,混沌计算俱乐部(CCC)获取了其中一部分数据。 CCC是一个安全研究小组,负责识别安全问题;CCC已经确认他们没有持有从AWS S3 Bucket下载的任何数据. 我们没有证据可以证实没有其他第三方获得数据。 Twilio不拥有这个桶, 我们的系统都没有 与数据曝光有关。 这起事件是Dident Mobile在Twilio控制之外采取行动的结果。 虽然我们继续与这些载体合作,为你们提供有关这一接触的最准确信息,但身份移动公司披露的数据中与2024年1月1日至2024年5月15日发送的短信有关的部分包括: • 移动电话号码 • 短信内容 • 短信发信人身份证 • 短信时间戳 我们迄今做了什么? • Twilio启动了事件应对进程,以迅速调查此事。 Twilio将此事升级为iBasis执行团队; • 为了谨慎起见,我们已尽可能停止向iBasis发送交通信号。 iBasis告知Twilio,它已经停止了与"识别机动"的通路. · 我们将继续与我们第3方的航空母舰合作,以获得这一事件可能产生的任何额外细节。 你要怎么办? 我们建议审查您在2024年1月1日至2024年5月15日期间发送的短信流量, 与您的内部团队讨论接触的影响, 如果你需要更多关于这起事件的信息 我们在此支持你 我们对此可能造成的任何不便深表遗憾并赞赏你的理解与合作。 ————————————————————————————————. 状态卡斯特做了什么? 一旦StautsCast的安全小组接到警报,就进行了一次审计,试图确定这对我们服务的潜在影响。 根据Twilio的报告,通过StateCast服务发送的一些通知有可能是使用iBasis载体发送的。 根据报告,数据应包括接收者的电话号码以及短信。 状态卡斯特的短消息通知旨在简洁并驱动用户到状态页. 短消息不包括收件人姓名或其他个人可识别信息(PII). 您有权选择是否发送短信通知 。 如果您想要审查您的配置, 可以在应用程序的设置和集成部分控制短消息选项 。 目前,在StateCast的应用或基础设施方面没有可采取的额外行动项目,但是我们将与Twilio保持密切的沟通,如果发布任何其他信息,我们将通过我们自己的地位网页予以传递。 StautsCast多年来一直与Twilio合作,他们一直坚定致力于安全和透明度。 我们将继续在申请中发出短消息通知时,也将考虑到这一事件。 如有其他问题请联系我们@statuscast.com

2. 2024年7月5日 UTC 13:01resolved

   自动关闭

自动翻译自官方事件更新。

1. 2024年6月7日 UTC 13:00update

   在4米收购之后,我们一直在准备将StencilsCast的支助业务纳入4米基础设施。 通过将我们的支援行动与4me的支援行动结合起来,我们的顾客将拥有24x7的支援优势,可用的代表人数将几乎翻了四番. 为了在正式合并这些团队方面迈出第一步,我们将从2024年6月7日星期五开始取消行政门户中可用的直播聊天选项. 您可以继续通过电子邮件( [email protected]) 或访问我们目前的支持门户来获得支持。 在接下来的几个月里,您将会注意到StateCast支持方式的几个变化. 这将涉及引入一个新的、经改进的支助门户,以跟踪你通过支助记录的任何更改请求或问题。 此外,还将在应用程序中提供更多的工具和审计信息,直接获得的帮助和知识资源将有所增加。 我们非常兴奋能以4米扩大我们的支持!

2. 2024年6月7日 UTC 13:01resolved

   自动关闭

自动翻译自官方事件更新。

1. 2024年4月4日 UTC 00:19update

   在大约8:19PM EDT时,StatusCast的工程师被告知,一些状态页面和管理员应用程序无法访问。 小组确认,其东道伙伴微软正在美国东部地区遇到一些与应用服务和SQL数据库连接有关的问题。 截至9:03PM EDT服务已经恢复,StateCast的团队目前正在与微软合作,全面调查事件. 一旦调查组完成调查,我们将利用RCA采取后续行动。 现在,StatusCast应如预期的那样全面运作,如果您仍有进一步的问题,请通过[email protected]与我们联系

2. 2024年4月4日 UTC 01:03resolved

   截至9:03PM EDT服务已经恢复,StateCast的团队目前正在与微软合作,全面调查事件. 一旦调查组完成调查,我们将利用RCA采取后续行动.

3. 2024年4月5日 UTC 21:00update

   在与微软合作中,StateCast的团队证实中断的原因是位于Azure的美国东部地区的SQL数据库停用,而StateCast主要在这里: StatusCast本身受到大约8:19 PM EDT停电的影响,9:03 PM EDT完全恢复. StateCast的团队将继续与微软密切合作,以进一步优化其报价,帮助确保服务供应商停电的影响尽可能小.

自动翻译自官方事件更新。

1. 2024年4月2日 UTC 13:00update

   We are very excited to announce that StatusCast has been acquired by 4Me! Since 2013 we have been working hard to close the gap between service outages and those who are impacted, and this acquisition is one large step further in our journey of providing critical information to those who need it most. The inclusion of StatusCast's features will aid 4Me in it's mission to modernize service management for organizations. Click here to read more!

2. 2024年4月2日 UTC 13:01resolved

   auto-closed

1. 2024年3月8日 UTC 15:01investigating

   We are experiencing SMS delivery delays when sending messages to Telefonica Network In Mexico. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 1 hour or as soon as more information becomes available.

2. 2024年3月8日 UTC 15:12investigating

   We are continuing our investigation and have discovered SMS Latin America is affected by SMS delivery delays when sending messages to Telefonica Network in Mexico.

3. 2024年3月8日 UTC 16:22monitoring

   We are observing recovery in SMS delivery delays when sending messages to Telefonica Network in Mexico. We will continue monitoring the service to ensure a full recovery. We will provide another update in 2 hours or as soon as more information becomes available.

4. 2024年3月8日 UTC 16:23resolved

   auto-closed

1. 2024年3月8日 UTC 13:26investigating

   We are continuing to experience SMS Delivery Delays when sending messages to Multiple Networks in Thailand. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 2 hours or as soon as more information becomes available.

2. 2024年3月8日 UTC 15:20monitoring

   We are observing recovery in SMS delivery delays when sending messages to Multiple Networks in Thailand. We will continue monitoring the service to ensure a full recovery. We will provide another update in 2 hours or as soon as more information becomes available.

3. 2024年3月8日 UTC 17:05resolved

   We are no longer experiencing SMS delivery delays when sending messages to Multiple Networks in Thailand. This incident has been resolved.

1. 2024年3月7日 UTC 07:27investigating

   We've become aware of a potential issue with SMS Message Delivery delay to Tigo Network In Chad. Our engineering team has been alerted and is actively investigating. We will update as soon as we have more information.

2. 2024年3月7日 UTC 07:37investigating

   We are experiencing SMS delivery delays when sending messages to Tigo Network In Chad. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 1 hour or as soon as more information becomes available.

3. 2024年3月7日 UTC 07:43investigating

   We are experiencing SMS delivery delays when sending messages to Tigo Network In Chad. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 1 hour or as soon as more information becomes available.

4. 2024年3月7日 UTC 08:34investigating

   We are continuing to experience SMS delivery delays when sending messages to Tigo Network In Chad. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 2 hours or as soon as more information becomes available.

5. 2024年3月7日 UTC 10:28investigating

   We are continuing to experience SMS delivery delays when sending messages to Tigo Network In Chad. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 4 hours or as soon as more information becomes available.

6. 2024年3月7日 UTC 14:18investigating

   We are continuing to experience SMS delivery delays when sending messages to Tigo Network in Chad. Our engineers are working with our carrier partner to resolve the issue. We will provide another update in 8 hours or as soon as more information becomes available.

7. 2024年3月7日 UTC 15:12monitoring

   We are observing recovery in SMS delivery delays when sending messages to Tigo Network In Chad. We will continue monitoring the service to ensure a full recovery. We will provide another update in 30 min or as soon as more information becomes available.

8. 2024年3月7日 UTC 15:13resolved

   auto-closed