Cron over REST

Set a real CRON_SECRET

The endpoint compares the bearer token against CRON_SECRET and refuses anything else with a 403. Leave the variable unset and VitNode falls back to default-cron-secret-change-in-production - a value published in this documentation, which makes the endpoint effectively open to anyone who can guess your domain.

CRON_SECRET=b7c1f0e2d9a84c53b6e1f7a02d48c9e5

Point a scheduler at the endpoint

Once a minute, whatever the schedules on your jobs say. The endpoint runs what is due at the moment it is called, so the tick interval is the finest resolution any job can have - and core's own process-queue job is * * * * *, so a slower tick means queue tasks sit around waiting.

Your scheduler needs three things, and this is where providers differ:

A GitHub Actions workflow is the version with no account to create:

name: VitNode cron
on:
  schedule:
    - cron: '*/5 * * * *'
  workflow_dispatch:

jobs:
  tick:
    runs-on: ubuntu-latest
    steps:
      - run: |
          curl --fail-with-body -X POST "$API_URL/api/@vitnode/core/cron" \
            -H "Content-Type: application/json" \
            -H "Authorization: Bearer $CRON_SECRET"
        env:
          API_URL: ${{ vars.API_URL }}
          CRON_SECRET: ${{ secrets.CRON_SECRET }}

Five minutes, not one: GitHub's shortest schedule interval is five minutes, and runs on a busy shared queue are often later than that. It is a fine way to keep daily jobs honest and a poor way to drain a queue.

Verify it from the AdminCP

Send the request by hand once. A 200 with a job count means the endpoint accepted you; open /admin/core/advanced/cron and the rows you expected to run now show a Last Run of a moment ago.

Then leave the scheduler to it and check back. Last Run drifting behind a job's schedule is the symptom of a tick that is not arriving, and it is the only signal that reflects an external scheduler - see the gotcha about the Integrations screen below.