Historial de interrupciones de Statuscast

1. 29 de octubre de 2025 a las 16:04 UTCupdate

   Entre las 15:45 UTC el 29 de octubre y las 00:05 UTC el 30 de octubre de 2025, los clientes y los servicios de Microsoft aprovechando Azure Front Door (AFD) experimentaron retrasos, timeouts y errores. Los servicios de entrega del CDN de AFD siguen siendo estables y se ejecutan según lo previsto. De una gran precaución, todas las operaciones de gestión de servicios (incluyendo la creación, actualizaciones, eliminaciones y purgas) a AFD a través de portales o APIs siguen suspendidas temporalmente. Estamos trabajando en un plan amplio para reenviabilidad gradual de estos en un enfoque gradual, asegurando al mismo tiempo que la plataforma permanece estable. Seguiremos compartiendo actualizaciones periódicas a medida que avancemos. Siguiente actualización será para 01:00 UTC el 31 Oct 2025 o antes.

2. 31 de octubre de 2025 a las 1:08 UTCupdate

   Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados totalmente a las 00:05 UTC el 30 de octubre de 2025 y permanecen en niveles operativos normales. Al completar nuestra investigación completa e implementar nuevos controles seguros, las operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) son temporalmente indisponibles. Notificaremos a los clientes una vez que se levante la restricción, y enviaremos comunicación periódica sobre el progreso. Next Update será antes de las 19:00 UTC el 31 de octubre de 2025 o antes como orden de evento.

3. 31 de octubre de 2025 a las 20:03 UTCupdate

   Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados totalmente a las 00:05 UTC el 30 de octubre de 2025 y permanecieron en niveles operativos normales. Al completar nuestra investigación completa e implementar nuevos controles seguros, las operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) son temporalmente indisponibles. Estamos trabajando para proporcionar un ETA sobre cuándo podemos levantar la restricción y seguir enviando comunicación periódica sobre el progreso a través de Azure Service Health. La siguiente actualización será antes de las 19:00 UTC el 01 de noviembre de 2025 o antes como orden de eventos.

4. 31 de octubre de 2025 a las 21:35 UTCupdate

   Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados totalmente a las 00:05 UTC el 30 de octubre de 2025 y permanecieron en niveles operativos normales. Al completar nuestra investigación completa e implementar nuevos controles seguros, las operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) son temporalmente indisponibles. Nuestra expectativa actual es levantar la restricción el 05 de noviembre de 2025, y continuaremos enviando comunicación periódica sobre el progreso a través de Azure Service Health. La siguiente actualización será antes de las 19:00 UTC el 01 de noviembre de 2025 o antes como orden de eventos.

5. 1 de noviembre de 2025 a las 19:41 UTCupdate

   Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados totalmente a las 00:05 UTC el 30 de octubre de 2025 y permanecieron en niveles operativos normales. Al completar nuestra investigación completa e implementar nuevos controles seguros, las operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) son temporalmente indisponibles. Nuestra expectativa actual sigue elevando la restricción el 05 de noviembre de 2025, y continuaremos enviando comunicación periódica sobre el progreso a través de Azure Service Health. La siguiente actualización será antes de las 19:00 UTC el 02 de noviembre de 2025 o antes como orden de eventos.

6. 2 de noviembre de 2025 a las 20:31 UTCupdate

   Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados totalmente a las 00:05 UTC el 30 de octubre de 2025 y permanecieron en niveles operativos normales. Al completar nuestra investigación completa e implementar nuevos controles seguros, las operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) son temporalmente indisponibles. Nuestra expectativa actual sigue elevando la restricción el 05 de noviembre de 2025, y continuaremos enviando comunicación periódica sobre el progreso a través de Azure Service Health. La siguiente actualización será para las 03:00 UTC el 03 de noviembre de 2025 o antes como orden de eventos.

7. 2 de noviembre de 2025 a las 21:07 UTCupdate

   Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados totalmente a las 00:05 UTC el 30 de octubre de 2025 y permanecieron en niveles operativos normales. Al completar nuestra investigación completa e implementar nuevos controles seguros, las operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) son temporalmente indisponibles. Nuestra expectativa actual sigue elevando la restricción el 05 de noviembre de 2025, y continuaremos enviando comunicación periódica sobre el progreso a través de Azure Service Health. La siguiente actualización será para las 03:00 UTC el 03 de noviembre de 2025 o antes como orden de eventos.

8. 3 de noviembre de 2025 a las 3:02 UTCupdate

   Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados totalmente a las 00:05 UTC el 30 de octubre de 2025 y permanecieron en niveles operativos normales. Al completar nuestra investigación completa e implementar nuevos controles seguros, las operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) son temporalmente indisponibles. Nuestra expectativa actual sigue elevando la restricción el 05 de noviembre de 2025, y continuaremos enviando comunicación periódica sobre el progreso a través de Azure Service Health. La siguiente actualización será antes de las 19:00 UTC el 03 de noviembre de 2025 o antes como orden de eventos.

9. 4 de noviembre de 2025 a las 0:14 UTCupdate

   Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados totalmente a las 00:05 UTC el 30 de octubre de 2025 y permanecieron en niveles operativos normales. Como parte de completar nuestra investigación completa y cheques seguros, las operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) se hicieron temporalmente indisponibles. Las restricciones a las operaciones de gestión de servicios se han eliminado para este ID de suscripción de Azure. Por favor, permita aproximadamente 30–40 minutos para que los cambios se propagan completamente a los sitios de bordes. Esperamos que todas las restricciones a través de las suscripciones, incluyendo otras suscripciones bajo su arrendatario, sean levantadas antes del 05 de noviembre de 2025. Las actualizaciones sobre los progresos continuarán a través de Azure Service Health. La siguiente actualización será proporcionada por las 22:00 UTC el 04 de noviembre de 2025, o antes si las circunstancias cambian.

10. 4 de noviembre de 2025 a las 0:25 UTCupdate

    Reconocemos que la comunicación anterior puede haber contenido información destinada a otra lista de clientes. Nos disculpamos por la molestia y le pedimos que note lo siguiente. Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados totalmente a las 00:05 UTC el 30 de octubre de 2025 y permanecieron en niveles operativos normales. Al completar nuestra investigación completa e implementar nuevos controles seguros, las operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) son temporalmente indisponibles. El flujo de trabajo para gestionar y rotar Traiga su certificado propio (BYOC) certificados ha sido re-enabledo. Seguiremos de cerca el progreso de trabajar a través de la cola de las rotaciones necesarias. Seguiremos proporcionando actualizaciones periódicas sobre el progreso. Nuestra expectativa actual sigue elevando la restricción el 05 de noviembre de 2025. La siguiente actualización será a las 22:00 UTC el 04 de noviembre de 2025 o antes como lo justifiquen los eventos.

11. 4 de noviembre de 2025 a las 3:27 UTCupdate

    En preparación para levantar las restricciones de la gestión de los servicios, se envió una comunicación incorrecta que indicaba que se había retirado rápidamente. Nuestra fecha actual para levantar todas las restricciones del plano de control sigue siendo 05 Noviembre 2025. La siguiente actualización será proporcionada por las 22:00 UTC el 04 de noviembre de 2025, o antes.

12. 4 de noviembre de 2025 a las 22:22 UTCupdate

    Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados totalmente a las 00:05 UTC el 30 de octubre de 2025 y permanecieron en niveles operativos normales. Al completar nuestra investigación completa e implementar nuevos controles seguros, las operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) son temporalmente indisponibles. Seguimos alcanzando nuestros hitos hacia la expectativa de levantar esta restricción el 05 de noviembre de 2025. La próxima actualización será enviada para confirmar una vez que esto haya sucedido, o antes si los eventos lo justifican.

13. 5 de noviembre de 2025 a las 23:36 UTCupdate

    Última actualización: A partir de las 23:00 UTC del 5 de noviembre, se han eliminado las restricciones 2025 a las operaciones de gestión de servicios de Azure Front Door (AFD) y Content Delivery Network (CDN). Ahora puede reanudar operaciones normales en el plano de gestión de servicios AFD. Para mejorar la seguridad y la protección, hemos ampliado los tiempos de propagación de configuración hasta 45 minutos. Se espera que las mejoras adicionales de la plataforma que se están llevando a cabo permitan optimizar los tiempos de propagación. Anterior Contexto: Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados completamente por 00:05 UTC el 30 de octubre de 2025 y permanecen en niveles operativos normales. Anteriormente le notificamos que, como parte de completar nuestra investigación completa y cheques seguros, realizar operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) fueron temporalmente restringidos. Esta notificación consiste en confirmar que esas restricciones temporales ya no se aplican. Siguientes pasos: Como se menciona en nuestro PIR preliminar estamos completando una retrospectiva interna para entender el incidente con más detalle. Una vez que esto se complete, que se espera dentro de aproximadamente 7 días, publicaremos nuestra Revisión final de Incidentes Post (PIR) - incluyendo un enlace para registrarse para una corriente en vivo de Azure Incident Retrospective, discutiendo el incidente y nuestros aprendizajes. Azure Front Door preguntas frecuentes (FAQ) Microsoft Aprende

14. 5 de noviembre de 2025 a las 23:42 UTCresolved

    Última actualización: A partir de las 23:00 UTC del 5 de noviembre, se han eliminado las restricciones 2025 a las operaciones de gestión de servicios de Azure Front Door (AFD) y Content Delivery Network (CDN). Ahora puede reanudar operaciones normales en el plano de gestión de servicios AFD. Para mejorar la seguridad y la protección, hemos ampliado los tiempos de propagación de configuración hasta 45 minutos. Se espera que las mejoras adicionales de la plataforma que se están llevando a cabo permitan optimizar los tiempos de propagación. Anterior Contexto: Los aviones de datos de entrega de Azure Front Door (AFD) y Content Delivery Network (CDN) fueron mitigados completamente por 00:05 UTC el 30 de octubre de 2025 y permanecen en niveles operativos normales. Anteriormente le notificamos que, como parte de completar nuestra investigación completa y cheques seguros, realizar operaciones de gestión de servicios (crear, actualizar, eliminar, purgar, etc.) fueron temporalmente restringidos. Esta notificación consiste en confirmar que esas restricciones temporales ya no se aplican. Siguientes pasos: Como se menciona en nuestro PIR preliminar estamos completando una retrospectiva interna para entender el incidente con más detalle. Una vez que esto se complete, que se espera dentro de aproximadamente 7 días, publicaremos nuestra Revisión final de Incidentes Post (PIR) - incluyendo un enlace para registrarse para una corriente en vivo de Azure Incident Retrospective, discutiendo el incidente y nuestros aprendizajes. Azure Front Door preguntas frecuentes (FAQ) Microsoft Aprende

Traducido automáticamente desde la actualización oficial del incidente.

1. 29 de octubre de 2025 a las 16:01 UTCupdate

   Entendemos que hay una salida global para MS Azure. Nuestro equipo es consciente del problema. Las páginas de estado y el portal de administración pueden no ser accesibles. Nos disculpamos por cualquier inconveniente.

2. 29 de octubre de 2025 a las 18:17 UTCupdate

   El outage de Microsoft Azure sigue afectando los nombres de los dominios, pero no el dominio status.page. Puede utilizar https:// supagename .status.page para acceder a su página y al portal de administración. Nos disculpamos por cualquier inconveniente.

3. 30 de octubre de 2025 a las 5:40 UTCresolved

   Los servicios están operativos ahora. Este evento ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 4 de abril de 2025 a las 13:37 UTCupdate

   Se ha alertado a los ingenieros de demoras en el procesamiento de notificaciones. Actualmente estamos investigando y seguiremos con más detalles.

2. 4 de abril de 2025 a las 18:30 UTCresolved

   A las 9:37 AM EDT se produjo un incidente que atrasó el procesamiento de notificación de incidentes. El incidente se resolvió completamente a las 2:30 PM EDT. Más detalles sobre la causa raíz seguirá. Los suscriptores todavía verían las páginas de estado como se esperaba, pero la notificación de incidentes se habría retrasado.

Traducido automáticamente desde la actualización oficial del incidente.

1. 27 de febrero de 2025 a las 14:53 UTCupdate

   Xurrent Adquires Zenduty SANTA BARBARA, Calif., 27 de febrero de 2025 – XurrentTM, la plataforma de gestión de servicios y operaciones diseñada para empresas modernas y proveedores de servicios gestionados, ha adquirido Zenduty, líder en soluciones de gestión de incidentes de vanguardia y alerta. Esta adquisición marca otro hito significativo en el viaje en curso de Xurrent para transformar la TI y redefinir cómo las organizaciones manejan los principales incidentes de principio a fin. Phil Christianson, director de producto de Xurrent, comentó: “Xurrent está emocionado de anunciar un avance importante en nuestras capacidades de ITOM. Nuestra adquisición StatusCast el pasado abril mejoró nuestra plataforma para mejorar dramáticamente las capacidades de las organizaciones para comunicar detalles de incidentes importantes. Ahora, con la adquisición de Zenduty, habilitaremos a TI para automatizar y simplificar la resolución de incidentes y la remediación de causa raíz, asegurando correcciones más rápidas y evitando incidentes repetidos”. Zenduty es un innovador en gestión de incidentes y alertas. La plataforma se ha ganado la reputación de permitir a los comandantes de incidentes reunir rápidamente los equipos adecuados en una sala de guerra virtual, problemas de triaje y resolución de la unidad rápidamente. Al integrar Zenduty con las robustas capacidades de gestión de servicios informáticos de Xurrent (ITSM), los clientes disfrutarán de operaciones informáticas integrales y de gestión de servicios de una sola plataforma unificada. Esta integración garantiza que cuando se produzca un incidente importante, las organizaciones no sólo pueden gestionar y resolver la cuestión con rapidez sino también aplicar un enfoque estructurado para evitar que vuelva a ocurrir. Zenduty faculta a los comandantes de incidentes para coordinar eficazmente los equipos de respuesta, mientras que la plataforma ITSM de Xurrent asegura que las tareas se asignan a los equipos adecuados, rastreados y completados a tiempo, lo que conduce una mejora continua entre los incidentes. Al integrar Zenduty con la plataforma ITSM de Xurrent, las organizaciones obtienen los siguientes beneficios clave: • Automatización de salas de guerra virtuales para respuesta rápida a incidentes. • Gestión y resolución rápida de incidentes. • Asegurar la rendición de cuentas para la terminación de las tareas de rehabilitación después del incidente. “La combinación de las herramientas de gestión de incidentes de alta calidad y alerta de Zenduty con el poder de Xurrent en la gestión mundial de servicios de TI, permitirá a nuestros clientes tomar el control total de sus operaciones de TI y gestión de servicios con un enfoque más moderno, conectado y automatizado”, dijo Kevin McGibben, CEO de Xurrent. “Con Xurrent, los equipos toman medidas antes, resuelven los incidentes más rápidos y se aseguran de que nunca vuelvan a suceder, completando tareas críticas con eficiencia, precisión y plena rendición de cuentas”. Acerca de Xurrent XurrentTM simplifica la gestión de operaciones ITSM y IT con automatización impulsada por AI. Nuestra plataforma simplifica los flujos de trabajo, mejora la colaboración y aumenta la productividad. Construido para la escalabilidad, Xurrent se adapta perfectamente a las necesidades cambiantes de las empresas modernas, minimizando el esfuerzo al tiempo que maximiza la eficiencia. Más información en www.xurrent.com . Acerca de Zenduty Zenduty es una solución de gestión de incidentes de extremo a extremo que proporciona alertas multicanal por correo electrónico, teléfono, SMS, Slack y Microsoft Teams para asegurar que su equipo sea notificado rápidamente durante las horas de servicio. Diseñado para mejorar la eficiencia de respuesta a incidentes, Zenduty ofrece características tales como alerta personalizable, programación on-call, e integraciones sin costuras con más de 150 herramientas, incluyendo Datadog, Jira y Slack. Las organizaciones que utilizan Zenduty han reportado mejoras significativas, incluyendo reducción de tiempo de inactividad, un aumento del 50% en tiempo medio para reconocer (MTTA) y tiempo medio para resolver (MTTR), y ahorro de costos. Para obtener más información, visite www.zenduty.com. Comunicado de prensa: https://www.xurrent.com/press-release/xurrent-acquires-zenduty-completing-the-incident-response-and-remediation-loop/

2. 27 de febrero de 2025 a las 14:54 UTCresolved

   auto cerrado

Traducido automáticamente desde la actualización oficial del incidente.

1. 23 de febrero de 2025 a las 14:00 UTCupdate

   Los ingenieros de StatusCast señalaron cierta degradación del procesamiento que podría haber causado retrasos en algunas acciones.

2. 24 de febrero de 2025 a las 2:00 UTCresolved

   El equipo ha identificado la cuestión.

Traducido automáticamente desde la actualización oficial del incidente.

1. 4 de febrero de 2025 a las 22:30 UTCupdate

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

2. 5 de febrero de 2025 a las 2:00 UTCresolved

   This has been resolved. We apologize for any inconvenience.

1. 29 de diciembre de 2024 a las 23:00 UTCupdate

   El dominio para acceder al portal de soporte de StatusCast ha sido actualizado en https://xurrent-statuscast-portal.xurrent.com/ . Mientras que el viejo dominio redirigirá a nuestro actual recomendamos actualizar sus marcadores adecuadamente.

2. 29 de diciembre de 2024 a las 23:01 UTCresolved

   auto cerrado

Traducido automáticamente desde la actualización oficial del incidente.

1. 25 de noviembre de 2024 a las 19:24 UTCupdate

   Los ingenieros de StatusCast identificaron una copia de seguridad en su procesamiento de antecedentes que está causando retrasos en algunas acciones de ser completados de forma oportuna.

2. 25 de noviembre de 2024 a las 20:32 UTCupdate

   Los ingenieros han determinado la causa raíz de la copia de seguridad en el procesamiento. Durante este tiempo hemos escalado el servicio que es responsable de ayudar a eliminar los elementos restantes más rápido.

3. 25 de noviembre de 2024 a las 22:06 UTCresolved

   Los servicios deberían funcionar según lo previsto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 16 de noviembre de 2024 a las 1:00 UTCupdate

   Los ingenieros de StatusCast han sido alertados a un posible evento impactante en el rendimiento que afecta a las páginas de estado y los tiempos de respuesta de la aplicación admin. Este evento no está afectando el procesamiento de notificaciones. Nos disculpamos por esta molestia y proporcionaremos una actualización en breve.

2. 18 de noviembre de 2024 a las 19:00 UTCresolved

   Todos los servicios deben ser plenamente funcionales y funcionar regularmente.

3. 27 de noviembre de 2024 a las 20:00 UTCupdate

   Los ingenieros de StatusCast determinaron que aproximadamente a las 8:00PM EST el 15 de noviembre de 2024, varios de los servidores de aplicaciones de StatusCast experimentaron un problema que causó que el tiempo de respuesta aumentara. La infraestructura de StatusCast en Azure está diseñada para realizar procedimientos de escalada para servicios bajo coacción, y para todos menos uno de los servicios de aplicación en cuestión esto se hizo restaurar con éxito el servicio a un nivel aceptable de rendimiento. El servicio de solicitud restante en la UE no escalaba correctamente y permaneció en un estado degradado durante varios días. El 18 de noviembre los ingenieros fueron alertados de que algunos clientes seguían experimentando retrasos en el tiempo de carga y en ese momento se corrigió el último servidor. Después de este evento se produjo el equipo de DevOps de StatusCast comenzó una auditoría de todos los procedimientos de escalado para asegurar que los servicios de aplicaciones en nuestras regiones operativas de Azure se adhieran a un proceso de escalado consistente y para asegurar que el monitoreo se despliegue correctamente a todos los servicios ya que tener un solo servicio de aplicación que permanezca en un estado degradado durante días no es aceptable.

Traducido automáticamente desde la actualización oficial del incidente.

1. 5 de septiembre de 2024 a las 13:00 UTCupdate

   Nuestro equipo está emocionado de anunciar la marca oficial de 4me al nombre Xurrent. Nuestra mirada refrescante y nuestra identidad actualizada captan la esencia de nuestro negocio, nuestra plataforma, nuestra visión y su valor. Nuestro nuevo look está siendo lanzado en un nuevo sitio web, materiales de marketing, y la aplicación Xurrent! Fechas importantes: • 5 septiembre (hoy!) • Un comunicado de prensa anunció el lanzamiento de la nueva marca. • ¡Nuestro nuevo sitio web está en directo! Echa un vistazo en www.xurrent.com. • 7 de septiembre • Todas las comunicaciones de Xurrent emanarán de nuestro nuevo dominio, www.xurrent.com. Esto significa correos electrónicos y cualquier otra comunicación oficial. ¿Qué significa esto para ti? A partir de ahora verás nuestra nueva marca en correos electrónicos, en el sitio web y en otras comunicaciones. Tenga la seguridad de que este cambio no afectará sus servicios actuales. Gracias por ser una parte apreciada de la familia Xurrent (antes 4me). Si bien nuestra apariencia está evolucionando, nuestra dedicación a la entrega de productos de primera calidad y excepcional atención al cliente sigue sin cambios. Nuestra misión y valores siguen conduciéndonos a medida que crecemos hacia un futuro dinámico y colaborativo.

2. 5 de septiembre de 2024 a las 13:01 UTCresolved

   auto cerrado

Traducido automáticamente desde la actualización oficial del incidente.

1. 1 de agosto de 2024 a las 17:45 UTCupdate

   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. 1 de agosto de 2024 a las 17:46 UTCresolved

   auto-closed

1. 30 de julio de 2024 a las 13:30 UTCupdate

   Los ingenieros de StatusCast fueron alertados antes de que algunos usuarios estaban experimentando problemas esporádicos tratando de conectarse a la página de estado y portal de administración. Nuestro proveedor de alojamiento, Microsoft Azure, nos ha alertado a través de su página de estado que están experimentando algunos problemas de red globalmente. Proporcionaremos una actualización tan pronto como esté disponible más información.

2. 30 de julio de 2024 a las 14:44 UTCupdate

   El acceso a las páginas de estado ha permanecido estable y Azure ha actualizado su estado indicando que se han iniciado procesos de reducción de pérdidas para mejorar su disponibilidad de servicios. Los ingenieros de StatusCast continuarán observando esto de cerca y publicarán actualizaciones adicionales según sea necesario.

3. 30 de julio de 2024 a las 20:47 UTCupdate

   La aplicación de StatusCast ha seguido siendo estable. Nuestros ingenieros continuarán observando el sistema de cerca ya que Microsoft no ha cerrado completamente el evento a su lado. Para más detalles específicos sobre el problema de Azure, consulte su página de estado. Proporcionaremos actualizaciones adicionales según sea necesario.

4. 30 de julio de 2024 a las 22:00 UTCresolved

   Microsoft ha cerrado el problema de su lado y la plataforma de StatusCast sigue funcionando como se esperaba. Una vez que Microsoft haya publicado más detalles sobre esto, proporcionaremos aquí en forma de RCA.

5. 1 de agosto de 2024 a las 17:07 UTCupdate

   De MICROSOFT: Declaración de Mitigation - Azure Front Door Problemas de acceso a un subconjunto de servicios de Microsoft ID de seguimiento: KTY1-HW8 ¿Qué pasó? Entre aproximadamente a las 11:45 UTC y 19:43 UTC el 30 de julio de 2024, un subconjunto de clientes puede haber experimentado problemas que se conectan a un subconjunto de servicios de Microsoft a nivel mundial. Los servicios afectados incluyeron Azure App Services, Application Insights, Azure IoT Central, Azure Log Search Alerts, Azure Policy, así como el propio portal Azure y un subconjunto de servicios Microsoft 365 y Microsoft Purview. ¿Qué sabemos hasta ahora? Un aumento inesperado de uso resultó en componentes de Azure Front Door (AFD) y Azure Content Delivery Network (CDN) que se ejecutan por debajo de umbrales aceptables, lo que llevó a errores intermitentes, tiempo de salida y picos de latencia. Si bien el evento inicial fue un ataque Distributed Denial-of-Service (DDoS), que activó nuestros mecanismos de protección DDoS, las investigaciones iniciales sugieren que un error en la implementación de nuestras defensas amplifica el impacto del ataque en lugar de mitigarlo. ¿Cómo respondemos? El impacto del cliente comenzó a las 11:45 UTC y empezamos a investigar. Una vez que se entendía la naturaleza del pico de uso, implementamos cambios de configuración de redes para apoyar nuestros esfuerzos de protección DDoS, y realizamos fallos para alternar las rutas de networking para proporcionar alivio. Nuestra configuración inicial de red cambia exitosamente la mayoría mitigada del impacto por 14:10 UTC. Algunos clientes reportaron menos del 100% de disponibilidad, que comenzamos a mitigar alrededor de 18:00 UTC. Procedimos con un enfoque de mitigación actualizado, primero lo hicimos en distintas regiones de Asia Pacífico y Europa. Después de validar que este enfoque revisado eliminó con éxito los efectos secundarios de la mitigación inicial, lo volamos a regiones de América. Las tasas de incumplimiento retornaron a niveles de preincidencia para 19:43 UTC - después de monitorear el tráfico y los servicios para asegurar que la cuestión se mitigó completamente, declaramos que el incidente mitigó a 20:48 UTC. Algunos servicios de aguas abajo tardaron en recuperarse, dependiendo de cómo fueron configurados para usar AFD y/o CDN. ¿Qué pasa después? Nuestro equipo estará completando una retrospectiva interna para entender el incidente con más detalle. Publicaremos un Preliminary Post Incident Review (PIR) dentro de aproximadamente 72 horas, para compartir más detalles sobre lo ocurrido y cómo respondimos. Después de completar nuestra retrospectiva interna, generalmente dentro de 14 días, publicaremos una Revisión Final de Incidentes con cualquier detalle adicional y aprendizajes. Para ser notificado cuando eso ocurra, y/o para mantenerse informado sobre futuros problemas de servicios de Azure, asegúrese de configurar y mantener alertas de Azure Service Health – estos pueden desencadenar correos electrónicos, SMS, notificaciones push, webhooks y más: https://aka.ms/ash-alerts. Para obtener más información sobre las revisiones del incidente de correos, consulte https://aka.ms/AzurePIRs. Finally, for broader guidance on preparing for cloud incidents, refer to https://aka.ms/incidentreadiness.

Traducido automáticamente desde la actualización oficial del incidente.

1. 22 de julio de 2024 a las 16:30 UTCupdate

   El equipo de apoyo de StatusCast y 4me están listos para dar el siguiente paso para migrar nuestros servicios de soporte del sistema de ticketing de StatusCast para utilizar 4me directamente para todas las solicitudes de cambio e incidentes. Este próximo paso en la integración de las operaciones de StatusCast a 4me finalmente le proporcionará mucha más información sobre las solicitudes que usted envía y su estado. ¿Qué está cambiando? El miércoles 24 de julio de 2024 El portal de soporte de StatusCast se transferirá a https://4me-statuscast-portal.4me.com/, este portal de autoservicio será su nuevo recurso para enviar nuevos boletos y ver el estado de los ya existentes que ha presentado. Este nuevo portal le dará un estado más preciso del ticket, y en caso de que solicite un cambio o se encuentre en un problema que requiera trabajo de desarrollo, tendrá visibilidad en el estado de que desde un desarrollo hasta un QA, hasta una perspectiva de producción. Además, los clientes podrán encontrar respuestas a sus preguntas caminando a través del portal que contiene una base de conocimiento que se extenderá mientras avanzamos. Estamos muy emocionados de traer esta visibilidad extendida a nuestros clientes ya que creemos que es un paso importante hacia adelante en el apoyo que proporcionamos. Como resultado de este cambio, el correo electrónico [email protected] ya no abrirá tickets. Tendrá que acceder al portal de autoservicio para presentar y acceder a solicitudes de apoyo. Un enlace a este portal de autoservicio se ha añadido al portal de administración de StatusCast y se puede acceder seleccionando el Ajustes > Centro de ayuda > Billetes de soporte Los administradores existentes de StatusCast han recibido acceso a este nuevo portal. Para acceder al Portal StatusCast, vaya a https://xurrent-statuscast-portal.xurrent.com/ y comience con ‘¿Has olvidado tu contraseña de 4me?’ (1) para que puedas enviar un correo electrónico para registrar tu contraseña del portal de soporte. Si no recibe un correo electrónico mientras hace esto es posible que no se le haya concedido acceso automatizado, en ese caso puede registrarse haciendo clic en “Registrarse como nuevo usuario” (2): El Portal StatusCast requiere que use una dirección de correo electrónico y establezca una contraseña con 18 caracteres.

2. 22 de julio de 2024 a las 16:31 UTCresolved

   auto cerrado

Traducido automáticamente desde la actualización oficial del incidente.

1. 5 de julio de 2024 a las 13:00 UTCupdate

   De acuerdo con nuestro compromiso con la seguridad y la transparencia queríamos informarle de que nuestro proveedor de SMS, Twilio, ha alertado a nuestro equipo de seguridad a un incidente ocurrido. A continuación se presenta la declaración recibida de Twilio, que da una descripción detallada del incidente y lo que se ha hecho: --- Twilio ha sido notificado por uno de nuestros portadores de respaldo, iBasis, que IdentificaMobile expuso inadvertidamente ciertos datos relacionados con SMS enviados por iBasis públicamente en Internet que incluían datos personales. Estamos escribiendo para informarle que algunos de sus datos personales y datos no personales (como datos relacionados con campañas de marketing) fueron accedidos por un grupo de investigación de seguridad mientras que fue expuesto públicamente por IdentificaMobile. Aunque este incidente estaba fuera del control de Twilio, lo tomamos muy en serio y estamos comprometidos a ayudarle a entender todo el impacto. ¿Qué necesitas saber? Con el fin de ofrecer mensajes en regiones específicas, Twilio confía en numerosos transportistas para maximizar la entrega a sus destinos finales. Twilio fue notificado que iBasis (un transportista de respaldo Twilio) había utilizado IdentificaMobile (más portador de copia de seguridad de iBasis) que permitió el acceso público inadvertidamente en un cubo AWS S3 durante el trabajo de desarrollo. La información contenida en este cubo se hizo pública del 10 al 15 de mayo de 2024 y se accedió entre el 13 al 14 de mayo de 2024. Basándonos en una investigación conjunta entre IDMobile y Amazon AWS, aprendimos que una parte de estos datos fue accedido por el Club de Computación de Caos (CCC). CCC es un grupo de investigación de seguridad que identifica cuestiones de seguridad; CCC ha confirmado que no están manteniendo ningún dato descargado del AWS S3 Bucket. No tenemos pruebas que nos permitan confirmar que ningún otro tercero accedió a los datos. Twilio no posee este cubo, y ninguno de nuestros sistemas ha sido comprometido en relación con esta exposición de datos. Este incidente fue el resultado de acciones tomadas por IdentificaMobile y fuera del control de Twilio. Si bien seguimos colaborando con estos transportistas para traerle la información más exacta sobre esta exposición, la porción de datos expuestos por IdentificaMobile relacionados con SMS enviado entre el 1 de enero de 2024 y el 15 de mayo de 2024, e incluyó: • Número móvil • Contenido del mensaje SMS • ID del remitente de SMS • SMS Timestamp ¿Qué hemos hecho hasta ahora? • Twilio inició nuestro proceso de respuesta a incidentes para investigar rápidamente este asunto. • Twilio intensificó esta cuestión al equipo ejecutivo de iBasis; posteriormente, hemos hecho un análisis de los registros de datos que se comprometieron a proporcionarle la mayor cantidad de información posible. • De mucha precaución, hemos dejado de enviar tráfico a iBasis cuando sea posible. iBasis informó a Twilio que ha dejado de routing con IdentificaMobile. • Continuaremos trabajando con nuestros transportistas de terceros para conseguirle cualquier detalle adicional que pueda surgir de este incidente. ¿Qué necesitas hacer? Recomendamos revisar el tráfico SMS que envió entre el 1 de enero de 2024 y el 15 de mayo de 2024, discutiendo las implicaciones de una exposición con su equipo(s) interno y decidiendo si necesita involucrarse con individuos afectados. Si necesita información adicional sobre este incidente, estamos aquí para ayudarle a lo largo de esta situación. Lamentamos profundamente cualquier inconveniente que esto pueda causar y apreciar su comprensión y cooperación. --- ¿Qué ha hecho StatusCast? Una vez que el equipo de seguridad de StautsCast fue alertado una auditoría fue realizada para intentar determinar el impacto potencial que esto tenía en nuestro servicio. Basado en el informe de Twilio es posible que algunas notificaciones enviadas a través del servicio de StatusCast hubieran sido enviadas utilizando el portador iBasis. Basado en los datos del informe habría incluido el número de teléfono del destinatario, así como el mensaje SMS. Las notificaciones de SMS en StatusCast están diseñadas para ser breves y para conducir a los usuarios a la página de estado. Los mensajes SMS no incluyen el nombre de los destinatarios u otra información personal identificable (PII). Como siempre en StatusCast tiene derecho a elegir si las notificaciones de SMS son enviadas o no. Las opciones de SMS se pueden controlar en las secciones Configuración e Integración de la aplicación si desea revisar sus configuraciones. En este momento no hay elementos de acción adicionales para que StatusCast tome en relación con su aplicación o infraestructura, sin embargo mantendremos una estrecha comunicación con Twilio y si se publica alguna información adicional la pasaremos a través de nuestra propia página de estado. StautsCast se ha asociado con Twilio durante años y han mantenido un firme compromiso con la seguridad y la transparencia. Tomaremos esto, así como este incidente en consideración, ya que seguimos ofreciendo notificaciones SMS en la aplicación. Si tiene alguna pregunta adicional, comuníquese con nosotros en [email protected]

2. 5 de julio de 2024 a las 13:01 UTCresolved

   auto cerrado

Traducido automáticamente desde la actualización oficial del incidente.

1. 7 de junio de 2024 a las 13:00 UTCupdate

   Tras la adquisición por 4me, nos hemos estado preparando para integrar las operaciones de apoyo de StatusCast en la infraestructura de 4me. Al combinar nuestras operaciones de apoyo con 4me’s, nuestros clientes tendrán la ventaja de 24x7 soporte y el número de representantes disponibles casi cuadruple. Para dar el primer paso adelante en la fusión oficial de estos equipos estaremos eliminando la opción de chat en vivo disponible en el portal de administración a partir del viernes 7 de junio de 2024. Puede seguir comunicando con soporte a través de correo electrónico ( [email protected] ) o accediendo a nuestro portal de soporte actual. En los próximos meses, usted notará varios cambios en cómo se proporciona el apoyo de StatusCast. Esto implicará la introducción de un portal de apoyo nuevo y mejorado para el seguimiento de cualquier solicitud de cambio o problemas que haya conectado con el apoyo. Además, se pondrán a disposición de la aplicación más herramientas e información de auditoría, y habrá un aumento de los recursos de ayuda y conocimientos accesibles directamente. Estamos muy emocionados de ampliar nuestra oferta de soporte con 4me y sabemos que finalmente ayudará a nuestra comunidad de clientes y usuarios valorados!

2. 7 de junio de 2024 a las 13:01 UTCresolved

   auto cerrado

Traducido automáticamente desde la actualización oficial del incidente.

1. 4 de abril de 2024 a las 0:19 UTCupdate

   Aproximadamente 8:19PM EDT, los ingenieros de StatusCast fueron alertados de que algunas aplicaciones de estado y administración eran inaccesibles. El equipo identificó que su socio de hospedaje, Microsoft, estaba experimentando algunos problemas en su región este de EE.UU. relacionados con servicios de aplicaciones y conexiones de bases de datos SQL. A partir de las 9:03PM se han restaurado los servicios de EDT y el equipo de StatusCast trabaja actualmente con Microsoft para investigar completamente el incidente. Una vez que el equipo haya completado su investigación vamos a seguir con un RCA. En este momento StatusCast debería estar operando plenamente como se esperaba, si sigues teniendo otros problemas, ponte en contacto con nosotros en [email protected]

2. 4 de abril de 2024 a las 1:03 UTCresolved

   A partir de las 9:03PM se han restaurado los servicios de EDT y el equipo de StatusCast trabaja actualmente con Microsoft para investigar completamente el incidente. Una vez que el equipo haya completado su investigación vamos a seguir con un RCA.

3. 5 de abril de 2024 a las 21:00 UTCupdate

   En el trabajo con Microsoft, el equipo de StatusCast confirmó que la interrupción se debió a un outage con SQL Databases ubicado en la región de EE.UU. de Azure, donde StatusCast se encuentra principalmente alojado: StatusCast mismo fue impactado por este outage de aproximadamente 8:19 PM EDT y se había recuperado completamente para las 9:03 PM EDT. El equipo de StatusCast seguirá trabajando estrechamente con Microsoft para optimizar aún más su oferta para ayudar a asegurar que el impacto de los outages del proveedor de servicios sea lo más mínimo posible.

Traducido automáticamente desde la actualización oficial del incidente.

1. 2 de abril de 2024 a las 13:00 UTCupdate

   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. 2 de abril de 2024 a las 13:01 UTCresolved

   auto-closed

1. 8 de marzo de 2024 a las 15:01 UTCinvestigating

   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. 8 de marzo de 2024 a las 15:12 UTCinvestigating

   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. 8 de marzo de 2024 a las 16:22 UTCmonitoring

   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. 8 de marzo de 2024 a las 16:23 UTCresolved

   auto-closed

1. 8 de marzo de 2024 a las 13:26 UTCinvestigating

   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. 8 de marzo de 2024 a las 15:20 UTCmonitoring

   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. 8 de marzo de 2024 a las 17:05 UTCresolved

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

1. 7 de marzo de 2024 a las 7:27 UTCinvestigating

   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. 7 de marzo de 2024 a las 7:37 UTCinvestigating

   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. 7 de marzo de 2024 a las 7:43 UTCinvestigating

   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. 7 de marzo de 2024 a las 8:34 UTCinvestigating

   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. 7 de marzo de 2024 a las 10:28 UTCinvestigating

   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. 7 de marzo de 2024 a las 14:18 UTCinvestigating

   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. 7 de marzo de 2024 a las 15:12 UTCmonitoring

   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. 7 de marzo de 2024 a las 15:13 UTCresolved

   auto-closed