Jobs programados

La API trae sus jobs in-process con Bun.cron: comparten pool y estado con el servidor, no necesitan un proceso aparte.

Jobs

Job	Schedule	Qué hace
`reservas.expirar`	`* * * * *`	Expira apartados vencidos (lote de 500)
`notificaciones.procesar`	`/2 * * *`	Envía un lote de la cola (50)
`notificaciones.recordatorios`	`0 6 * * *`	Encola recordatorios (ventana 24 h)
`auth.purgar`	`0 3 * * *`	Borra sesiones/intentos vencidos

Cada handler atrapa sus errores: una promesa rechazada sin catch tumba el proceso. Los logs se ven como [cron] reservas.expirar ok {…}.

Configuración

Variable	Efecto
`CRON_ENABLED=false`	No programa ningún job (útil en réplicas que solo sirven tráfico)
`CRON_TZ="America/Mexico_City"`	Zona horaria de los `0 6` y `0 3` (vacío = hora local del servidor)

Disparo manual

Los jobs con efecto externo tienen endpoint HTTP equivalente, protegidos con el header x-cron-secret (valor de CRON_SECRET):

# Expirar apartados vencidos ahora (idempotente)
curl -X POST http://localhost:5000/reservas/expirar \
  -H "x-cron-secret: $CRON_SECRET"

# Enviar un lote de la cola
curl -X POST http://localhost:5000/notificaciones/procesar \
  -H 'content-type: application/json' \
  -H "x-cron-secret: $CRON_SECRET" -d '{"limite":50}'

# Encolar recordatorios
curl -X POST http://localhost:5000/notificaciones/recordatorios \
  -H 'content-type: application/json' \
  -H "x-cron-secret: $CRON_SECRET" -d '{"horasAnticipacion":24}'

Todos son idempotentes: correrlos dos veces no duplica efectos.

auth.purgar no expone endpoint (solo cron).

Siguiente paso

→ Variables de entorno