Vercel cron job not running: what Vercel skips, and how to hear about it

The deployment is not Production

Vercel triggers a cron job with an HTTP GET request to the project's production deployment URL, and its troubleshooting guide says it plainly: "Cron jobs only run on Production deployments." A cron added on a preview deployment does nothing until it reaches Production.

Hobby runs once a day, somewhere in the hour

On the Hobby plan a cron job can run once per day, and an expression that runs more often fails the deployment with Hobby accounts are limited to daily cron jobs. This cron expression would run more than once per day. Timing is per hour: 0 1 * * * can run any time between 1:00 and 1:59. Pro and Enterprise run once per minute at most, within the minute specified. Every plan allows 100 cron jobs per project.

The time is UTC

"The timezone is always UTC." Vercel also rejects names such as MON or JAN, and day of month and day of week cannot both be set: when one has a value, the other must be *. The cron expression explainer lists the next runs of an expression in UTC and in your own zone.

Cron jobs are disabled for the project

Settings → Cron Jobs → Disable Cron Jobs applies to the whole project, persists across deployment promotions and Instant Rollbacks, and stays off until someone re-enables it. Disabled cron jobs are still listed, so the list looks normal.

The route redirects

"Cron jobs do not follow redirects." A 3xx response ends the invocation, and the redirect does not show in the logs. With trailingSlash enabled, the cron path needs its trailing slash.

The response comes from a cache

A cached response also leaves no log entry, and your code never runs. In a Next.js route handler, Vercel's troubleshooting guide suggests export const dynamic = 'force-dynamic'.

The request is refused before your code runs

With CRON_SECRET set, Vercel sends it as Authorization: Bearer <secret>. A secret with a newline or characters that cannot go in a header fails that check, so your route answers 401 every time. Custom firewall rules can block the request as well.

The path or the build does not match

A cron for a path that does not exist still runs and gets a 404. If a route was renamed, the path in vercel.json must follow it. To confirm the crons were registered, run vercel build --prod and look for the crons property in .vercel/output/config.json.

The function runs out of time

Cron jobs have the same duration limits as Vercel Functions, set with maxDuration. A job that needs longer is stopped part-way, and Vercel does not retry it: "Vercel will not retry an invocation if a cron job fails."

The run was never delivered

Vercel calls cron delivery best effort: "occasional transient network errors can prevent a request from reaching your function. In those cases, your function does not execute, and no runtime log is created for that scheduled run." The same scheduled run can also arrive twice, so make the job idempotent.

Create a monitor with the cron's schedule

In the console, create a monitor with the same expression as the vercel.json entry, timezone UTC. On Hobby, make the grace window longer than an hour, because the run can come any time in its hour. Copy the ping URL into a LASTPING_URL environment variable on the project.

{
  "crons": [
    { "path": "/api/cron/nightly", "schedule": "0 3 * * *" }
  ]
}

Ping start, success and failure from the route

Check the secret the way Vercel's documentation shows, then wrap the work. A ping that cannot be delivered is caught, so it never fails the job:

// app/api/cron/nightly/route.ts
export const dynamic = 'force-dynamic'

const ping = process.env.LASTPING_URL!
const send = (suffix = '', body?: string) =>
  fetch(ping + suffix, { method: body ? 'POST' : 'GET', body }).catch(() => {})

export async function GET(request: Request) {
  const secret = process.env.CRON_SECRET
  if (!secret || request.headers.get('authorization') !== `Bearer ${secret}`) {
    return new Response('Unauthorized', { status: 401 })
  }
  await send('/start')
  try {
    await runNightlyJob()
    await send()
    return Response.json({ ok: true })
  } catch (err) {
    await send('/fail', String(err).slice(0, 10000))
    return new Response('Job failed', { status: 500 })
  }
}

/start arms overrun detection, so a function stopped at its maximum duration shows as a run that started and never finished.