La edad del último artefacto vivo funciona como un SLO simple para un feed diario

La ausencia de error no significa frescura. Un archivo puede seguir disponible, responder 200 y tener JSON válido mientras está dos días atrasado. Uptime tradicional no detecta ese fallo porque técnicamente el recurso existe. La edad del último artefacto vivo agrega la dimensión que importa a un producto editorial: cuánto tiempo ha pasado desde la fecha que debería estar visible. Cuando esa edad supera el presupuesto acordado, existe degradación aunque ninguna API haya lanzado una excepción.

La fórmula puede ser deliberadamente simple. Toma la hora local actual y compárala con feedDate o con un timestamp de publicación verificable. Para un feed diario, el objetivo normal es que la diferencia nunca cruce el siguiente cambio de día. Si a las primeras horas de la mañana el vivo todavía muestra ayer, la métrica empieza a crecer. La simplicidad facilita alertas, dashboards y conversaciones con personas no técnicas.

El umbral depende de la promesa editorial. Un sitio de breaking news necesitaría minutos; NewsDesk puede aceptar una edición diaria. El SLO debe reflejar esa expectativa y no copiar un número genérico. Por ejemplo, se puede permitir una pequeña ventana de publicación después de medianoche y considerar crítico cualquier atraso que llegue al mediodía. Definirlo antes de un incidente evita acomodar el criterio a lo que terminó ocurriendo.

La métrica funciona incluso cuando el scheduler falla. Si una tarea nunca se dispara, no habrá log de error dentro del run. La edad del vivo seguirá aumentando y revelará el problema desde fuera. Esa independencia es valiosa porque un monitor que depende del mismo scheduler comparte su modo de fallo. Leer directamente el recurso final crea una observación más fuerte sobre la experiencia real del producto.

También puede guiar prioridades de recuperación. Si vivo está actualizado pero staging de mañana falta, todavía existe margen. Si vivo ya tiene dos días de edad, recuperar el día actual debe superar cualquier preparación futura. La métrica ayuda a ordenar acciones cuando hay varios huecos. En lugar de seguir un checklist fijo, el sistema atiende primero la desviación que ya afecta al lector.

Conviene combinar edad con integridad. Una edición recién publicada pero incompleta no está sana. Por eso el SLO de edad debe acompañarse de controles de items, IDs y hash. Una métrica responde frescura; la otra responde integridad. Juntas evitan dos falsos positivos opuestos: archivo viejo pero válido, o archivo nuevo pero corrupto. Mantenerlas separadas permite diagnosticar cuál dimensión falló.

El histórico permite medir confiabilidad mensual. Registrar la edad máxima diaria muestra cuántas veces el producto superó su presupuesto y cuánto duraron esos episodios. Esa serie permite saber si una reparación realmente mejora continuidad. También ayuda a diferenciar incidentes aislados de un patrón donde cada pocos días el feed vuelve a quedarse atrás por la misma causa.

Un SLO útil debe empujar una acción. La edad del vivo no necesita convertirse en un dashboard decorativo. Cuando cruza el umbral, la respuesta puede ser concreta: verificar staging, reanudar promoción o generar el hueco actual. Una métrica operativa vale porque reduce el tiempo entre degradación y corrección. Para un producto diario, saber inmediatamente que la fecha visible quedó atrás puede ser más útil que cien logs internos sobre tareas que parecieron ejecutarse.

Haz visible la edad junto a la edición. Mostrar internamente feedDate, hora de verificación y edad calculada evita que un archivo viejo parezca sano solo porque carga correctamente. Esa información puede aparecer en un panel operativo pequeño y alimentar la misma recuperación. Cuando el equipo ve que el indicador vuelve a cero después de publicar, obtiene una confirmación simple de que el ciclo diario regresó a su presupuesto de frescura.