node-cron

@vitnode/node-cron is the in-process cron adapter: a node-cron timer that lives inside your API process and posts to the cron endpoint once a minute. No external service, no scheduler dashboard, nothing to keep in sync - which is exactly why it only works where your API is a long-lived process.

Before you beginCopy Anchor Link

• An API that runs as a long-lived Node process: a self-hosted server, a container or your dev machine.
• VITNODE_API_URL set to the address the API answers on, if that is not http://localhost:3000. The tick is a request to that address.
• A random CRON_SECRET on production servers. In development the built-in default works.

Set up the adapterCopy Anchor Link

bun i @vitnode/node-cron

import { buildApiConfig } from '@vitnode/core/vitnode.config'
import { NodeCronAdapter } from '@vitnode/node-cron'

export const vitNodeApiConfig = buildApiConfig({
  cron: NodeCronAdapter(), 
  // ...
})

bun dev

Check the resultCopy Anchor Link

Open Debug Panel → Cron & queue (/admin/core/debug/cron) and find the process-queue row. Core schedules it every minute, so within a minute of the restart its Time column shows a last run, and that last run never gets more than a minute old while the adapter is alive. The scheduler card above the table turns green: All jobs on schedule.

If the last run stays empty, read the server console for a [VitNode] Cron tick failed line, then see the gotchas below.

What the adapter actually doesCopy Anchor Link

The whole package is the file below, and knowing it saves an afternoon of debugging:

import { type CronAdapter, handleCronJobs } from '@vitnode/core/api/lib/cron'
import { schedule } from 'node-cron'

export const NodeCronAdapter = (): CronAdapter => {
  return {
    schedule() {
      schedule(
        '*/1 * * * *',
        async () => {
          await handleCronJobs()
        },
        { noOverlap: true },
      )
    },
  }
}

handleCronJobs() is an HTTP request to your own API - POST /api/@vitnode/core/cron, with Content-Type: application/json and Authorization: Bearer $CRON_SECRET. The adapter never touches the database and never calls a job handler; it only knocks on the door once a minute, and the cron endpoint decides what is due.

noOverlap skips a tick while the previous request is still waiting, and the request gives up after 55 seconds - the API keeps running the jobs, it just stops making the ticker wait. Running several API instances? Each one ticks, but every due job is claimed in core_cron first, so it runs on exactly one of them.

Three consequences worth writing down:

GotchasCopy Anchor Link

RelatedCopy Anchor Link