Toda tarea que corre sola a una hora fija tiene un punto ciego: nadie sabe si funcionó hasta que alguien nota que no llegó el reporte, que el cliente no recibió su recordatorio o que el inventario de la tienda dejó de coincidir con el del sistema. Cloudflare movió una pieza que reduce ese punto ciego, y conviene que sepas qué significa aunque no escribas una línea de código.
Qué anunció Cloudflare
El 17 de octubre de 2026, Cloudflare publicó que su Local Explorer ya puede disparar a mano las tareas programadas de un Worker (los llamados Cron Triggers) mientras el sitio o el sistema se está construyendo en una computadora, no en el servidor real.
Antes, probar una de esas tareas obligaba a armar una URL de prueba a mano. Ahora el flujo es otro:
- Se levanta el servidor de desarrollo local con cf dev, wrangler dev o el plugin de Vite para Cloudflare.
- Se abre la ruta /cdn-cgi/local/explorer en la dirección de ese servidor local.
- Se elige Cron Triggers y desde ahí se invoca la tarea.
La interfaz permite invocar las expresiones cron ya configuradas, construir expresiones ad hoc (por ejemplo, una que en producción nunca correría), guardar horarios reutilizables y revisar el resultado, incluido el estado de noRetry().
Hay un detalle que vale oro para quien paga: los disparos ad hoc y los horarios guardados se quedan en el navegador. No cambian cloudflare.config.ts, no cambian la configuración de Wrangler y no tocan los Cron Triggers desplegados. Se puede probar sin riesgo de alterar lo que ya está en producción.
Puedes leer el anuncio completo en el changelog de Cloudflare.
Por qué le importa a tu negocio y no solo al programador
Las tareas programadas son la parte de un sistema que nadie mira hasta que falla. Y cuando fallan, no avisan: no hay pantalla en rojo, no hay mensaje de error para el dueño. Simplemente no pasa lo que tenía que pasar.
Piensa en lo que ya corre en tu operación:
- El recordatorio de cita que sale la tarde anterior.
- El cierre de caja que se genera al final del día.
- La sincronización de stock entre el sistema administrativo y la tienda online.
- El aviso de “tu pedido salió” en una empresa de logística.
- El respaldo de la base de datos de clientes.
Si esa tarea está mal escrita, el error aparece en el peor momento: cuando el cliente reclama, cuando el contador pide el reporte o cuando el inventario ya no cuadra y hay que revisar a mano. Ahí el costo no es técnico, es de horas de tu equipo y de confianza del cliente.
Lo que cambió es que ahora ese comportamiento se puede provocar a voluntad durante la construcción, en la computadora de quien desarrolla, sin esperar a que den las 8:00 de la noche y sin tocar el sistema que ya está atendiendo clientes. Una tarea que se puede disparar cuando quieras es una tarea que se puede corregir antes de que te cueste dinero.
Lo que esta novedad no resuelve
Conviene tenerlo claro para no pedir milagros:
- El servidor local no ejecuta los horarios solo. Hay que dispararlos desde la interfaz. No es una simulación del paso del tiempo.
- Los registros completos dependen de una configuración. Las trazas aparecen en la sesión de desarrollo que tiene el Worker cuando esa sesión tiene Observability encendido.
- Sigue siendo una prueba local. Que funcione en la computadora no garantiza que el proveedor de correo, la pasarela de pago o el servicio externo respondan igual el día real. Reduce el riesgo, no lo elimina.
Antes y ahora, en la práctica
| Situación | Antes | Ahora |
|---|---|---|
| Probar el envío del reporte diario | Esperar la hora o construir una URL de prueba a mano | Disparar la tarea desde el navegador |
| Probar el caso raro (último día del mes, mes sin datos) | Modificar configuración y cruzar los dedos | Expresión ad hoc, sin tocar la configuración |
| Repetir la misma prueba varias veces | Rearmar todo cada vez | Horario guardado en el navegador |
| Riesgo de alterar lo desplegado | Dependía del cuidado de cada quien | No cambia la configuración ni los cron desplegados |
También existe una API local que hace exactamente lo mismo, pensada para herramientas y agentes de automatización. Es decir, la prueba de estas tareas se puede integrar a un flujo de trabajo y no depender de que alguien se acuerde de hacer clic.
Qué pedirle a quien te construye la automatización
No necesitas aprender a programar para verificar esto. Necesitas hacer cinco preguntas y exigir que te las respondan con hechos, no con promesas:
- Muéstrame la tarea corriendo. No una captura del código: la ejecución ocurriendo y su resultado visible.
- Prueba el caso raro. Qué pasa el último día del mes, el día que no hay datos, el día que el servicio externo responde con error.
- Define qué ocurre cuando falla. Si hay reintento, si hay aviso, y sobre todo quién se entera y por dónde.
- Confirma que se puede repetir sin tocar producción. Que la prueba viva en el entorno de desarrollo y no en el sistema que ya está en uso.
- Pide un registro consultable. Sin historial de ejecuciones, nadie puede decir si la tarea corrió o no.
Estas cinco preguntas aplican igual si la automatización es un recordatorio de citas para una clínica, un aviso de entrega para una empresa de logística o el cierre de caja de un restaurante. Si quieres una idea más amplia de qué conviene automatizar primero, tenemos una guía de qué automatizar en logística para entregas más rápidas y otra sobre cuánto cuesta automatizar un negocio en Venezuela.
Un último punto sobre alcance: una landing page, un sitio completo y un e-commerce tienen fecha de entrega comprometida. Una automatización o una integración no entra en esos paquetes, porque depende de sistemas de terceros que hay que revisar primero. Ese caso se consulta y se define con el alcance por delante.
Las tareas que corren solas son las que más silencio hacen cuando se rompen. Poder dispararlas a mano durante la construcción es la diferencia entre descubrir el problema tú o descubrirlo tu cliente.