Cómo crear un health check de publicación diaria

Empieza por el recurso que ve el usuario. El primer paso es descargar el vivo fijo y parsearlo. Comprueba feedDate, número de items, IDs, distribución y BOM. Si la fecha no es la actual, el health check ya tiene una conclusión operativa: el feed está atrasado. No necesita consultar primero diez estados internos. Priorizar el recurso final mantiene la comprobación alineada con la experiencia que el producto realmente entrega.

Revisa staging con una expectativa temporal. Antes del mediodía, staging puede legítimamente contener la edición del día actual o anterior. Después de la hora de preparación, debería contener mañana. El health check calcula esa fecha esperada según la hora local y verifica estructura y hash. Si vivo está sano pero staging no, la acción es preparar mañana; no hay razón para tocar producción todavía.

Busca backup después de publicación. Cuando vivo tiene la fecha correcta, comprueba que exista un único latest-news-<runKey>.json en la carpeta histórica del día. Descárgalo y compara hash con vivo. El nombre por sí solo no basta, porque un archivo antiguo puede haberse copiado con una etiqueta nueva. La igualdad de bytes demuestra que el respaldo sirve para reconstruir exactamente lo publicado.

Confirma el correo por asunto exacto. Busca en Gmail Sent Goatify NewsDesk publicado - <runKey>. Si vivo y backup son correctos pero el correo falta, la reparación debe enviar solo el correo. No regeneres la edición ni vuelvas a escribir vivo. El health check debe reducir trabajo duplicado al identificar el hueco más tardío que todavía permanece incompleto.

Devuelve estados pequeños y mutuamente excluyentes. Un resultado como LIVEMISSINGTODAY, STAGINGMISSINGTOMORROW, BACKUPMISSING, EMAILMISSING o HEALTHY es más accionable que un párrafo narrativo. Cada estado puede mapearse a una rutina de recuperación. Si aparecen varias fallas, prioriza por dependencia: primero vivo, después backup, luego correo, y finalmente preparación futura.

Incluye evidencia mínima. Guarda fecha observada, IDs, byte size, hash y timestamp de la comprobación. Esos campos permiten comparar dos health checks y saber si el sistema avanzó. No hace falta copiar todo el JSON ni llenar otro repositorio de logs. La evidencia debe ser suficiente para demostrar qué se vio y por qué se eligió la siguiente acción.

Ejecuta el check también fuera de las horas principales. Una comprobación a media tarde puede detectar que la preparación de mañana faltó aunque la publicación de hoy esté bien. Otra después de medianoche puede validar el commit. El objetivo no es añadir muchas automatizaciones separadas, sino permitir que la misma lógica de NewsDesk use el health check como primera fase cada vez que corre.

Mantén el health check read-only. La comprobación no debería modificar nada. Su tarea es observar y decidir. Separar lectura de reparación hace más fácil depurar y evita que diagnosticar un estado cause otro cambio inesperado. Cuando el check concluye qué falta, una segunda fase ejecuta la mutación necesaria y vuelve a correr las mismas verificaciones. Esa simetría simplifica la recuperación.

Prueba el health check con fallos simulados. Crea casos donde vivo esté ayer, staging tenga una fecha equivocada, el backup falte o el correo no exista. Verifica que cada escenario produzca exactamente el estado y la acción esperados. Estas pruebas son baratas porque el health check es de lectura. Al convertir incidentes conocidos en casos reproducibles, cada cambio de lógica puede demostrar que no reintroduce errores que ya habían dejado el feed atrasado.