Resumen
- Zoom abrió la incidencia my4rs36dn5tf a las 12:09:51 UTC con impacto menor en la región de Estados Unidos.
- El primer aviso se limitó al listado de Whiteboards; a las 12:24:12 se añadió la imposibilidad de crear Tasks.
- Zoom afirmó a las 12:33:25 que había identificado la causa, pero no la hizo pública.
- La primera fase pasó a observación a las 12:45:35 y así constaba al corte informativo de las 14:06:29.
- Tras el corte, ambos componentes volvieron a degradarse a las 14:28:05 y regresaron a observación a las 14:49:23.
- La incidencia se cerró a las 15:08:45 sin cifra de afectados, tasa de error, causa ni declaración de integridad de datos.
El expediente contiene dos episodios
Desde el inicio hasta la primera observación transcurrieron 35 minutos y 44 segundos. En ese momento, el estado de Whiteboard y Tasks volvió a ser operativo.
La segunda degradación apareció a las 14:28:05. Por tanto, las casi tres horas entre apertura y cierre no equivalen a una caída continua, pero tampoco permiten considerar definitiva la primera mejora.
La lectura útil es bifásica: restauración inicial, periodo de aparente estabilidad y reaparición del mismo perímetro funcional.
La secuencia amplió el trabajo afectado
El aviso inicial solo decía que los usuarios no podían listar Zoom Whiteboards en la región estadounidense. No afirma que los tableros se borraran, que todas las rutas de acceso fallaran o que su contenido quedara dañado.
Quince minutos después, Zoom incorporó la creación de Tasks. El problema pasó así de localizar un artefacto compartido a registrar una acción futura.
No hay constancia de degradación del audio o el vídeo de Zoom Meetings. Una reunión podía continuar mientras fallaba la capa que conserva decisiones y responsabilidades.
El corte no debe reescribirse con datos posteriores
La ventana fija terminó a las 14:06:29 UTC. Entonces, la primera recuperación llevaba unos 81 minutos bajo observación y el campo de resolución seguía vacío.
La reincidencia se publicó 21 minutos y 36 segundos después. Debe incluirse para completar la historia, no para afirmar que el servicio ya estaba degradado al cierre.
Mantener los dos relojes evita convertir una alerta contemporánea en un relato retrospectivo disfrazado.
Identificar no es explicar
Zoom publicó dos mensajes de causa identificada, uno por fase, con texto casi idéntico. Ninguno nombra una dependencia, un despliegue, una saturación o una medida correctiva.
La recaída podría responder a una mitigación parcial, una reversión o un fallo distinto que alcanzó los mismos componentes. La evidencia no permite escoger una hipótesis.
El estado público aporta certeza sobre los cambios de servicio, no sobre su mecanismo.
El daño aparece en la reconciliación
Cuando una Task no puede crearse, el equipo suele registrarla en chat, correo o notas privadas. Cuando vuelve el servicio, esas copias provisionales pueden perderse o duplicarse.
Un listado incompleto de Whiteboards también puede hacer que una persona abra un tablero paralelo, fragmentando el registro de una reunión. El riesgo no es solo el minuto de indisponibilidad, sino la divergencia posterior.
Sin cuentas afectadas, porcentaje de peticiones fallidas ni segmentación de clientes, no es posible valorar el impacto agregado.
El cierre no confirma qué ocurrió con cada intento
La segunda fase pasó a observación a las 14:49:23 y quedó resuelta a las 15:08:45, dos horas, 58 minutos y 54 segundos después de la apertura administrativa.
Ese intervalo incluye tiempo con ambos componentes operativos. Tampoco demuestra que las operaciones rechazadas se reintentaran automáticamente.
Zoom no informó de pérdida o corrupción, pero tampoco emitió una garantía específica sobre colas, escrituras o tareas pendientes.
Recuperar exige comprobar el registro de trabajo
Las organizaciones deberían cotejar las decisiones tomadas durante ambos episodios con las Tasks finalmente visibles, revisar responsables y fechas y eliminar duplicados.
Guardar identificadores de tableros fuera de la vista de listado y mantener un acta exportable reduce la dependencia de una sola interfaz.
Faltan una explicación posincidente, métricas de fallo y una declaración sobre escrituras pendientes o rechazadas. Hasta que aparezcan, la conclusión más firme es operativa: Zoom recuperó dos veces las mismas funciones y no explicó por qué la primera recuperación no se sostuvo.