Cron Setup For Send Jobs And Workflows

Endpoints To Schedule

Mailbase uses authenticated internal endpoints for background email work. Run them from your host cron, Vercel Cron, GitHub Actions, a worker scheduler, or any scheduler that can send an HTTP bearer token.

Both endpoints accept GET or POST for scheduler compatibility. POST is preferred when your platform supports it.

Cron Secret

Set CRON_SECRET in production and send it as a bearer token. INTERNAL_CRON_SECRET is accepted as a legacy alias. In local development without either secret, the endpoints allow calls so you can test the worker loop.

curl -X POST https://mailbase.example.com/api/internal/send-jobs \
  -H "Authorization: Bearer $CRON_SECRET"

Deployment Pattern

• Create one schedule for /api/internal/send-jobs every minute.
• Create one schedule for /api/internal/workflows every minute if you use Journeys or date/time automation triggers.
• Set DATABASE_URL, AUTH_SECRET, CRON_SECRET, and your workspace sending credentials before enabling production cron.
• Keep the schedule frequent. Job rows control next_run_at, batch size, retries, and per-workspace concurrency, so duplicate scheduler ticks are safe.

Operational Checks

• The send worker returns scheduled campaign counts, processed recipient counts, and per-batch results.
• Runnable send-job states are queued, running, and retrying. Terminal states are sent, failed, and cancelled.
• Failed recipient details are stored on send_job_items.error and shown in the campaign failed-recipient view.
• The /api/health endpoint includes safe component checks for cron-sensitive dependencies.