Product

Cron jobs

A Stackap cron job is a schedule and a path: at each scheduled time Stackap calls that path on your app and records whether the call succeeded.

What it does

You define a job with a name, a standard five-field cron schedule and a path that starts with a slash. The scheduler is built into the platform, so there is no separate worker to run or pay for. When a job comes due, Stackap makes the request to your running app and stores the result.

If your project already has cron entries in a vercel.json file, you can import them in one step with stackap cron import <slug> vercel.json. The job name is derived from the path. A set of 73 scheduled jobs from a real multi-tenant product passes the importer's validation.

Every run is recorded with its status and any error, and the list of jobs shows the status and time of the last run, so an agent or a person can see which job is failing without reading logs.

How it works

Schedules are evaluated in UTC, always. A schedule written for another time zone has to be converted by hand, and daylight saving changes will shift the local hour. This matches how the hosted cron it imports from behaves.

On each tick the scheduler looks for jobs whose most recent scheduled time has no run recorded yet and starts one, so a job is not skipped if a tick is late. A monitor check summarizes the cron system as healthy, warning when some jobs are flaky, and failing when some are down.

• List jobs and their last result: stackap cron ls <slug>.
• Create or change a job through the API: PUT /v1/projects/:slug/cron/:name with a schedule, a path and an enabled flag.
• Read a job's run history: GET /v1/projects/:slug/cron/:name/runs.

In practice

$ stackap cron import my-app vercel.json
$ stackap cron ls my-app

Early-access scope

• A job can only call a path on your own app. It cannot run a shell command or a script.
• Schedules are UTC only. There is no time-zone setting.
• If you move from another host, stop its cron jobs the moment the new ones are live, or every job will run twice.
• Whether a job is retried after a failure is not a feature to rely on. Design endpoints to be safe to call again.
• One server runs the scheduler, so a server outage pauses every job.

Questions

Last updated 2026-10-03.