For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /es/docs/modules/schedules.md (or send Accept: text/markdown).
Tareas programadas
Trabajo recurrente por workspace mediante las schedule actions.
Guía paso a paso para principiantes
Requisitos previos: lea las dos guías para principiantes a continuación, finalice la configuración local web y abra este monorepo en la raíz de su editor. La configuración web pertenece a apps/web/.env.local; Next.js no lee la raíz .env. /dashboard en el modo falso predeterminado es una demostración sin base de datos; /auth necesita una base de datos migrada.
Términos breves: un espacio de trabajo son los usuarios, datos y configuraciones separados de un equipo. El servidor es el backend confiable; Mantenga las claves del proveedor fuera del código del navegador y del teléfono. Una migración es un cambio de base de datos versionada que crea o actualiza tablas. Un modelo de IA es el motor que responde; el catálogo de modelos es la lista del servidor de ID de modelos disponibles y precios. Un proveedor es un servicio externo, como inteligencia artificial, correo electrónico o servicio de facturación. Un derecho es una concesión que permite que un espacio de trabajo utilice una función. Un webhook es un mensaje que un servicio envía al URL de otro servicio.
1. Abra Settings → Developers y use los controles de Programaciones para crear un trabajo de prueba con un tiempo de ejecución de UTC.
2. Mantenga la aplicación en ejecución y haga que el mismo SCHEDULER_TICK_SECRET de servidor esté disponible para la aplicación y el terminal; ejecute el siguiente comando desde la raíz del repositorio.
3. Confirme que avanza el tiempo de vencimiento y el trabajo alcanza su propio estado. Si no se ejecuta nada, verifique la hora de UTC, el proveedor del programador y los registros del servidor; Nunca pegues el secreto en el chat.
Para obtener código personalizado, comience con el prompts/README.md proporcionado y copie el mensaje más cercano: prompts/new-app-screen.md para una pantalla de aplicación o prompts/new-landing-page.md para una página pública. Para trabajos de servidor, base de datos o proveedor, asigne a su agente de codificación la tarea de esta guía y pídale que lea AGENTS.md, .ai/PROJECT_CONTEXT.md y los espejos .ai/ correspondientes; inspeccionar los archivos fuente exactos nombrados aquí; enumerar archivos y verificaciones antes de editarlos; preservar la propiedad del espacio de trabajo y los secretos exclusivos del servidor; y mostrarte la diferencia. Dígale el comportamiento que desea, los campos de entrada y salida, los roles permitidos, los éxitos y errores esperados y la cuenta, proveedor o dispositivo de prueba. Utilice valores de muestra; Nunca pegues un verdadero secreto.
- Antes de comenzar
- Conceptos básicos de terminales
- Configuración local web
- Mensajes del agente y memoria del proyecto
corepack pnpm jobs:tickGuarda el trabajo recurrente en la base de datos
La programación en Configuración guarda el tipo de trabajo y la regla cron en filas job_schedule con ámbito de espacio de trabajo. Los campos cron se evalúan en UTC. createDrizzleJobScheduler.claimDueSchedules reclama las filas vencidas mediante FOR UPDATE SKIP LOCKED, avanza su próxima ejecución y luego despacha los controladores.
El JobRunner genérico garantiza enqueue/status/cancel. La recurrencia pertenece a las filas del programador; la semántica del flujo de Trigger.dev sigue siendo explícita.
Ejecuta los ticks del programador
Configure un SCHEDULER_TICK_SECRET solo de servidor para habilitar POST /api/internal/scheduler-tick. corepack pnpm jobs:tick lo llama para desarrollo/CI; la configuración ausente devuelve 404. En JOB_PROVIDER=trigger, el cron scheduler.tick implementado controla el programador.
# Against a running local app, with SCHEDULER_TICK_SECRET configured:
corepack pnpm jobs:tickVerifica las reclamaciones y la ejecución por separado
Prueba ticks simultáneos, reglas de vencimiento, filas deshabilitadas, fallos de controladores, cancelación y la programación de otro espacio de trabajo. Inspecciona por separado la reclamación/actualización y la finalización del trabajo; una fila reclamada no demuestra que el trabajo haya terminado.
Configuración y ajustes
El trabajo programado — digests, limpiezas, renovaciones — pasa por schedule-actions en lugar de temporizadores ad hoc: listWorkspaceSchedules, upsertScheduleAction y removeScheduleAction gestionan las tareas cron de un workspace.
Un schedule nombra la tarea, la expresión cron y el workspace bajo el que corre. El worker resuelve el contexto en tiempo de ejecución, así un schedule pausado o eliminado deja de producir trabajo sin redespliegue.
listWorkspaceSchedules()
upsertScheduleAction({ task, cron })
removeScheduleAction(formData)Flujo de implementación
Trata cada ejecución programada como entrada no confiable: re-resuelve workspace y entitlement dentro de la ejecución, porque el estado pudo cambiar desde el registro. Haz la tarea idempotente — una ejecución reintentada o disparada dos veces no debe duplicar efectos.
Los schedules son superficie operativa: mantenlos visibles en settings o logs para que un schedule atascado o desbocado se encuentre antes de que los usuarios lo noten.
Verificación y solución de problemas
Dispara el schedule manualmente en un sandbox, pausalo, verifica que un workspace deshabilitado deja de producir ejecuciones y confirma que un disparo duplicado produce un solo efecto. Mantén las expresiones cron en configuración gestionada, no dispersas por el código de tareas.