El panel del planificador explicado

El trabajo programado es fácil de olvidar hasta que no ocurre. El panel del planificador en Dailybot existe para que ops y managers vean el tiempo como dimensión de primera clase: qué debió dispararse, qué se disparó y qué necesita atención. Este recorrido se centra en cómo leer la interfaz y usarla para resolver problemas de forma práctica.

Vistas principales: próximas, historial y agendas activas

Próximas ejecuciones responde la pregunta de planificación: «¿Qué se ejecutará después?» Deberían ver una línea de tiempo o lista ordenada por la próxima hora de ejecución, con contexto suficiente (nombre del flujo, alcance, zona horaria) para detectar solapamientos. Si dos trabajos pesados caen en el mismo minuto, aquí se nota antes de que sea un problema de límites de tasa.

Historial de ejecuciones es la pista de auditoría: ejecuciones pasadas con marcas de tiempo, pistas de duración y resultado. Ahí confirman si el digest de anoche corrió de verdad o si solo llegó el mensaje a Slack mientras un paso posterior no se completó.

Agendas activas (a veces agrupadas en otra pestaña o panel) listan las definiciones aún enroladas: expresiones cron, flujo dueño e interruptores de activar/desactivar. Cuando alguien dice «apaguen el rollup del viernes», aquí verifican el trabajo correcto—no otro de prueba con nombre parecido.

Cómo leer la línea de tiempo

Una buena línea de tiempo cuenta tres historias: qué corrió (marcas y registros), qué sigue (cola hacia adelante) y qué falló (errores o alertas). Miren hacia adelante en busca de huecos: si «próxima ejecución» salta demasiado lejos, investiguen pausas, ventanas de mantenimiento o flujos deshabilitados.

En cada entrada, noten el alcance: trabajos a nivel organización versus jobs con alcance de equipo se comportan distinto cuando cambia la membresía. Un run ligado a un equipo obsoleto puede aparecer como omitido hasta que reasignen responsabilidad.

Filtros: agente, equipo, flujo

Los filtros convierten un panel ruidoso en señal. Dimensiones típicas:

• Nombre del flujo o automatización — aislar un playbook.
• Alcance de equipo o canal — ver solo digest de customer success.
• Agente o integración — separar check-ins humanos de jobs impulsados por agentes.

Usen filtros al depurar un caso aislado («nunca me llegó el recordatorio») sin perder el contexto global de otras agendas.

Estados de ejecución

Completado significa que el planificador entregó el trabajo al ejecutor de automatizaciones y el flujo reportó éxito de punta a punta—aun así revisen salidas de vez en cuando, porque «verde» puede ocultar errores de lógica.

Omitido suele ligarse a condiciones: el reloj disparó, pero no se cumplieron prerequisitos (cohorte vacía, feature flag apagado o «sin datos nuevos desde la última corrida»). Omitido no es malo por sí; es problema solo cuando esperaban que hubiera trabajo.

Fallido indica error: timeout de integración, cambio de permisos, payload mal formado o cuota excedida. Abran el detalle de la ejecución para ver texto de error e identificadores de correlación que soporte pueda usar.

Reintentando muestra manejo de fallos transitorios: la plataforma puede esperar y volver a intentar. Ojo con trabajos atrapados reintentando—suele señalar credencial o configuración persistentemente rota, no un fallo de red puntual.

Resolver ejecuciones perdidas o fallidas

Partan del historial, no del chat. Confirmen si existe alguna fila. Si no hay fila, la agenda puede estar deshabilitada, el flujo borrado o la zona horaria cambió. Si hay una fila omitida, lean el motivo antes de ejecutar manualmente.

Para filas fallidas, corrijan la causa raíz primero (renovar token, ajustar alcance) y luego usen reintento si el producto lo ofrece; reintentar a ciegas sin arreglo malgasta cupos y ensucia registros.

Documenten la cadencia esperada por trabajo crítico (dueño, propósito de negocio, escalamiento). El panel es más poderoso junto a una nota de ops de una página: «Si X no publica para las 09:05 UTC, revisen Y».

Hábitos compartidos entre managers y ops

Los managers deberían saber dónde mirar y quién es dueño de las agendas; ops debería mantener definiciones ordenadas (sin dos cron duplicados haciendo lo mismo). Un escaneo semanal de cinco minutos de fallos evita sorpresas de fin de mes cuando todos asumieron que la automatización seguía corriendo.

Usado con constancia, el panel del planificador convierte trabajos de fondo invisibles en infraestructura observable—la diferencia entre esperar que el bot recordara y saber que lo hizo.