(Tareas cron · Nautilus)
¿Has chocado con el límite del planificador de tu plataforma? Nautilus llama a cualquier URL pública con el calendario cron que definas, hasta una vez por minuto. Una llamada fallida se reintenta, cada intento queda registrado y los calendarios se definen por una API en lugar de en un archivo de configuración. Los calendarios corren en UTC.
curl -X POST https://api.vernesoft.com/v1/clockwork/jobs \
-H "Authorization: Bearer vrn_clockwork_•••" \
-d '{"name":"billing","schedule":"0 0 1 * *","url":"https://api.yourdomain.com/billing"}'(Dónde se acaba cron)
Un crontab va bien en una máquina, y el planificador de una plataforma va bien dentro de su plataforma. Los problemas empiezan en el borde: el plan gratuito que permite una ejecución al día, el segundo servidor que lanza dos veces la misma tarea, el fallo que nadie vio.
Crontab y planificadores de plataforma
Tareas cron en Nautilus
(Características principales)
(01)
El calendario vive con nosotros, no en cada instancia de tu app, así que escalar tu app no puede multiplicarlo. De nuestro lado, cada ejecución pendiente se reserva en la base de datos antes de lanzarse, de modo que un segundo worker que ve la misma tarea la encuentra ya tomada.
(02)
Crea, pausa, cambia y elimina calendarios por la API, o programa una tarea puntual para una hora concreta. Si tus clientes definen sus propias tareas recurrentes en tu producto, tu backend crea la tarea cuando ellos guardan.
(03)
Una ejecución fallida recibe hasta tres intentos: el primero y luego reintentos uno y cinco minutos después. El estado de los reintentos vive con la tarea y no en memoria, así que un reintento pendiente sobrevive a un reinicio del worker o a un despliegue.
(04)
El planificador despierta una vez por minuto y lanza lo que toca, así que una tarea fijada a las 09:00 empieza en la primera comprobación a las 09:00 o después, no en algún punto de la hora. No hay campo de segundos, y todos los calendarios corren en UTC.
(05)
Cada intento queda registrado con su hora de inicio, cuánto tardó, el estado HTTP que devolvió tu endpoint y el cuerpo de la respuesta, o el error si la llamada nunca llegó a conectar. El historial se conserva durante la ventana de tu plan, que está en la página de precios.
(06)
Expresiones cron estándar de 5 campos, resueltas en UTC: no hay zonas horarias ni macros abreviadas como daily o hourly. Un calendario que restringe a la vez el día del mes y el día de la semana se rechaza en lugar de adivinarse, y lo mismo uno que nunca puede dispararse.
(Parte de Nautilus)
Las tareas cron son una parte de Nautilus, en la misma cuenta y el mismo panel que el inicio de sesión y la entrega de webhooks. El planificador es código nuestro. El inicio de sesión y la entrega de webhooks corren sobre motores de código abierto que podrías alojar tú mismo; esta parte no se va contigo si te marchas. Lo que sí se va contigo: cada tarea y cada ejecución se puede leer por la API.
(Experiencia de desarrollador)
Dale una expresión cron y una URL, con un SDK oficial o una petición HTTP normal. Una tarea puntual lleva en su lugar una marca de tiempo UTC.
curl -X POST https://api.vernesoft.com/v1/clockwork/jobs \
-H "Authorization: Bearer $VERNE_CLOCKWORK_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Monthly Billing Run",
"schedule": "0 0 1 * *",
"url": "https://api.yourdomain.com/billing/process",
"method": "POST",
"body": "{\"batch\":\"auto\"}"
}'(FAQ)
El calendario vive con nosotros, así que añadir instancias de tu app no cambia nada. De nuestro lado, cada ejecución pendiente se reserva con una actualización condicional en la base de datos antes de que se lance nada: un segundo worker que ve la misma tarea encuentra la fila ya avanzada y no hace nada. Eso te da un disparo por hueco programado. La entrega en sí es al menos una vez, porque un intento fallido se reintenta, así que haz tu endpoint idempotente y usa la cabecera X-Clockwork-Attempt para proteger los efectos secundarios.
Cada ejecución recibe hasta tres intentos: el primero y luego reintentos uno y cinco minutos después. Los fallos de red, los 5xx y los 429 se reintentan; otras respuestas 4xx no, porque un reintento idéntico recibiría la misma respuesta. Cada intento espera hasta 30 segundos una respuesta, y las redirecciones no se siguen, así que indica la URL final. Cada intento queda registrado con la respuesta que devolvió, y un reintento pendiente sobrevive a un reinicio del worker.
Sí. Además de las expresiones recurrentes, puedes programar una tarea puntual para una marca de tiempo UTC, por ejemplo enviar un correo 24 horas después del registro. Se recoge en la comprobación de una vez por minuto del planificador, como todo lo demás aquí.
Sí. Una tarea es una llamada HTTP a una URL pública, así que puede apuntar a una ruta de tu despliegue en Vercel, con las cabeceras que necesite para pasar tus propias comprobaciones, hasta una vez por minuto. La función sigue corriendo en Vercel, así que se aplican los límites de duración y uso de Vercel; Nautilus solo hace la llamada, y esas ejecuciones no cuentan para tu cuota de solicitudes. Para que conste, la documentación de Vercel (consultada el 3 de octubre de 2026) incluye cron en todos los planes, también Hobby, pero limita Hobby a una ejecución al día con precisión solo de una hora; Pro se ejecuta por minuto. Los demás se detienen en sus propios bordes: pg_cron solo alcanza lo que tu base de datos puede alcanzar, y un calendario de GitHub Actions puede empezar tarde con mucha carga, según su propia documentación.
Crea una tarea diferida a un minuto con POST /v1/clockwork/delayed y obsérvala en el registro de ejecuciones. Todavía no hay un botón de ejecutar ahora. Una ejecución puntual usa el mismo worker y los mismos registros que una recurrente.
Sí, sin tarjeta. Clockwork no gasta tu cuota de solicitudes: ni las ejecuciones programadas ni las llamadas a la API de Clockwork cuentan para ella. Lo que limita cada plan es cuántas tareas están activas a la vez: el plan gratuito permite 10 tareas recurrentes y 100 tareas diferidas en espera, Starter 100 y 1.000, Pro 1.000 y 10.000. Starter cuesta 19 € y Pro 79 € al mes; la página de precios tiene la lista actual.
Hoy no. Nada envía una alerta cuando falla una ejecución. Cada intento queda registrado con el estado y el cuerpo que devolvió, y puedes leer el registro en el panel o consultar el endpoint de ejecuciones, así que una comprobación tuya puede dar la alarma.
(Empieza)
Las tareas cron son una parte de Nautilus: la misma cuenta y el mismo panel que el inicio de sesión y la entrega de webhooks.
Cuándo no necesitas esto
Si ejecutas una aplicación en una máquina, crontab está bien y deberías quedártelo. Lo mismo vale para el trabajo que nunca sale de su plataforma: Vercel Cron sirve para una función de Vercel, pg_cron sirve para un job que solo toca tu base de datos de Supabase, y una programación de GitHub Actions basta para una tarea nocturna que puede permitirse llegar tarde.
Nautilus se gana su sitio en el límite donde esos se detienen, y ese límite llega antes de lo que la gente espera. La segunda instancia, donde dos copias del mismo crontab lanzan dos veces la misma facturación. La tarea que tiene que llamar a un servicio en otro host. El calendario que tus propios clientes fijan desde tu panel. El plan gratuito que lanza una tarea diaria en algún punto de la hora. La ejecución que falló a las 03:00 y no dejó rastro.
Esos cinco son los casos a los que responde Nautilus: una ejecución por calendario sin importar cuántas instancias despliegues, cualquier URL pública en cualquier host, calendarios creados y cancelados por una API, precisión de minuto en cada plan y un registro de cada intento con la respuesta que devolvió. Las ejecuciones programadas no cuentan para tu cuota de solicitudes, y el plan gratuito permite 10 tareas recurrentes activas.