Vercel Schedules: cron jobs serverless en beta pública

¿Qué es Vercel Schedules y qué reemplaza?

Vercel abrió Schedules en beta pública para todos los planes, con un precio que arranca en US$5 por millón de ejecuciones y US$10 por millón de creaciones en los planes Pro y Enterprise. La compañía detrás del framework Next.js presenta así el sucesor de sus Cron Jobs: tareas que corren en una cadencia recurrente o en un momento puntual, en producción, en preview o en entornos personalizados, y que se pueden habilitar, deshabilitar o ejecutar bajo demanda sin volver a desplegar.

Para un founder, el cambio no es cosmético. Hasta ahora, automatizar una tarea de fondo en Vercel solía terminar en un endpoint HTTP que cualquiera podía intentar invocar y que había que blindar con un secreto compartido. Con Schedules, esa tarea puede vivir en una función privada sin URL pública.

¿Cómo funciona un schedule estático en vercel.json?

Los schedules declarados en vercel.json pueden apuntar a tres destinos: una función privada de Vercel, una ruta HTTP o un topic de Vercel Queue. La definición combina la expresión cron, el destino y la zona horaria. Un caso típico es un schedule horario con la expresión 0 * * * * que apunta a api/cleanup.ts y fija la zona horaria en America/New_York.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Para que esa función sea privada hay que agregarle un trigger schedule/v1beta en su configuración. Ese detalle es el que cambia el modelo de seguridad: la función deja de tener URL pública y solo la infraestructura de schedules de Vercel puede invocarla.

Del lado del código, el manejo del dispatch se hace con handleSchedule, importado de @vercel/schedules. El handler recibe metadatos como el nombre del schedule y el momento programado (scheduledAt), lo que permite registrar cuándo corrió cada tarea y con qué nombre.

¿Se pueden crear schedules en tiempo de ejecución?

Sí, y es la parte más interesante para productos multi-tenant. Con Schedules.create() se define un schedule desde el propio código, pasando nombre, destino, expresión cron, zona horaria y un payload. La diferencia clave: los schedules creados en runtime apuntan a un topic de Vercel Queue, no a una función ni a un path HTTP.

Eso habilita patrones que antes exigían un cron global con lógica condicional adentro. En lugar de un job que recorre toda la base de datos, cada cliente puede tener su propia cadencia y disparar un topic con un payload específico, como el tipo de reporte o el identificador de la cuenta.

Vercel señala además que Schedules alimenta los schedules dinámicos de Eve y las tareas programadas experimentales en proyectos Nitro.

¿Cuánto cuesta Vercel Schedules?

El plan Hobby incluye 500 creaciones de schedules y 5.000 ejecuciones por mes. En Pro y Enterprise, el cobro arranca en US$5 por millón de ejecuciones y US$10 por millón de creaciones.

La lectura práctica: las ejecuciones son baratas y las creaciones son el rubro que hay que vigilar. Un schedule que corre cada hora son 24 ejecuciones diarias, un volumen que difícilmente mueva la aguja del costo. En cambio, si tu arquitectura crea un schedule por usuario o por workspace, el conteo de creaciones escala con tu base de clientes y conviene revisarlo antes de llevarlo a producción.

¿Qué significa esto para tu startup?

Cuatro movimientos concretos:

Migra tus Cron Jobs con la guía oficial, no a mano. Los Cron Jobs existentes siguen funcionando, así que una migración a medias deja dos mecanismos corriendo en paralelo y duplica ejecuciones. Revisa primero qué jobs tienes activos.
Convierte los endpoints de cron en funciones privadas. Si hoy tu tarea programada vive en una ruta HTTP protegida por un secreto, agregar el trigger schedule/v1beta elimina esa superficie de ataque: sin URL pública, sin secreto que rotar.
Prueba los jobs en preview antes de que toquen producción. Como los schedules corren también en entornos de preview y personalizados, puedes validar una limpieza de datos o un envío de reportes contra un entorno de prueba. Es la diferencia entre descubrir un bug en un job nocturno y descubrirlo con datos reales de clientes.
Aprovecha la ejecución bajo demanda. Poder correr un schedule sin redeploy sirve para reintentar una tarea que falló de madrugada sin esperar al ciclo siguiente ni publicar una versión nueva.

Errores comunes al adoptar Schedules

Asumir que cualquier schedule puede apuntar a cualquier destino. Los estáticos pueden ir a función privada, path HTTP o topic de Queue; los creados en runtime solo a un topic de Queue. Si tu diseño asume lo contrario, vas a rediseñar a mitad de camino.
Olvidar la zona horaria. La configuración acepta zonas explícitas como America/New_York o America/Los_Angeles. Un reporte diario de las 9 de la mañana sin zona horaria definida puede llegar a una hora incómoda para tus usuarios.
Ignorar el costo de las creaciones. Es el rubro que crece con la cantidad de clientes, no con el tráfico.

Conclusión

Schedules no es una función nueva más: es la señal de que la ejecución programada de tareas se está volviendo una pieza estándar de la infraestructura serverless, con seguridad y entornos incluidos. Para un equipo pequeño, el beneficio inmediato es menos código propio dedicado a proteger y orquestar tareas de fondo. Para un producto multi-tenant, la puerta que se abre es la personalización por cliente sin multiplicar la complejidad operativa.

La beta pública está disponible en todos los planes, así que el costo de probarla es bajo: elige un job no crítico, migra ese primero y mide. No se encontraron datos adicionales verificables de comparables de precio de otros proveedores en la investigación realizada para esta nota.