Managing Cron Jobs

To view your active cron jobs:

1. Select your project from the Edgenivo dashboard
2. Open Settings in the sidebar and select Cron Jobs

• Updating Cron Jobs: Change the expression in vercel.json file or the function's configuration, and then redeploy
• Deleting Cron Jobs: Remove the configuration from the vercel.json file or the function's configuration, and then redeploy
• Disabling Cron Jobs: Click the Disable Cron Jobs button

The Disable Cron Jobs setting applies to the project and persists across deployment promotions and Instant Rollbacks. If you disable cron jobs, they remain disabled until you explicitly re-enable them in the project's Cron Jobs settings.

It is possible to secure your cron job invocations by adding an environment variable called CRON_SECRET to your Edgenivo project. We recommend using a random string of at least 16 characters for the value of CRON_SECRET. A password generator, like 1Password, can be used to create one.

The value of the variable will be automatically sent as an Authorization header when Edgenivo invokes your cron job. Your endpoint can then compare both values, the authorization header and the environment variable, to verify the authenticity of the request.

Because Edgenivo sends the value in an HTTP header, use only characters that are valid in a header value, such as letters and numbers. Don't include line breaks or leading or trailing spaces, which can be added when you paste the value. If the header doesn't match the value your code reads, your endpoint returns 401 for every invocation.

import type { NextRequest } from 'next/server';
 
export function GET(request: NextRequest) {
  const authHeader = request.headers.get('authorization');
  const cronSecret = process.env.CRON_SECRET;
 
  if (!cronSecret || authHeader !== `Bearer ${cronSecret}`) {
    return new Response('Unauthorized', {
      status: 401,
    });
  }
 
  return Response.json({ success: true });
}

export function GET(request) {
  const authHeader = request.headers.get('authorization');
  const cronSecret = process.env.CRON_SECRET;
 
  if (!cronSecret || authHeader !== `Bearer ${cronSecret}`) {
    return new Response('Unauthorized', {
      status: 401,
    });
  }
 
  return Response.json({ success: true });
}

import type { NextRequest } from 'next/server';
 
export function GET(request: NextRequest) {
  const authHeader = request.headers.get('authorization');
  const cronSecret = process.env.CRON_SECRET;
 
  if (!cronSecret || authHeader !== `Bearer ${cronSecret}`) {
    return new Response('Unauthorized', {
      status: 401,
    });
  }
 
  return Response.json({ success: true });
}

export function GET(request) {
  const authHeader = request.headers.get('authorization');
  const cronSecret = process.env.CRON_SECRET;
 
  if (!cronSecret || authHeader !== `Bearer ${cronSecret}`) {
    return new Response('Unauthorized', {
      status: 401,
    });
  }
 
  return Response.json({ success: true });
}

import type { VercelRequest, VercelResponse } from '@vercel/node';
 
export default function handler(
  request: VercelRequest,
  response: VercelResponse,
) {
  const authHeader = request.headers.authorization;
  const cronSecret = process.env.CRON_SECRET;
 
  if (!cronSecret || authHeader !== `Bearer ${cronSecret}`) {
    return response.status(401).json({ success: false });
  }
 
  response.status(200).json({ success: true });
}

export default function handler(request, response) {
  const authHeader = request.headers.authorization;
  const cronSecret = process.env.CRON_SECRET;
 
  if (!cronSecret || authHeader !== `Bearer ${cronSecret}`) {
    return response.status(401).json({ success: false });
  }
 
  response.status(200).json({ success: true });
}

The authorization header will have the Bearer prefix for the value.

For those using TypeScript versions below 5.2, it's important to adapt the code to import NextResponse from 'next/server' and use NextResponse.json for the response. This ensures compatibility with earlier TypeScript versions in Next.js applications. In TypeScript 5.2 and above, the standard new Response pattern should be used.

A deployment captures CRON_SECRET from your project settings when it builds, and keeps that copy for its lifetime. Edgenivo invokes cron jobs on the production deployment serving your production domain, and sends that deployment's copy in the Authorization header.

Editing CRON_SECRET in project settings changes nothing until your next deployment. Edgenivo keeps sending the old secret, and your function keeps reading the old secret from the same deployment, so the check in your handler still passes.

Rotate CRON_SECRET by updating the environment variable, deploying, and then checking the first invocation:

1. Open Environment Variables in your project settings and edit CRON_SECRET for the Production environment.
2. Redeploy your project, or push a commit to your production branch. Every new deployment picks up the latest environment variable values.
3. Wait for the new deployment to become Current. Edgenivo sends the new secret from the next scheduled invocation onward.
4. Open Cron Jobs in your project settings, select View Log for the job, and confirm that the first invocation after the rotation returned a 2xx status.

Both the header and the secret your function reads come from one deployment. Your handler never sees a mismatched pair, so it doesn't need to accept the old and new secrets at once.

A 401 in the log means your handler rejected the secret Edgenivo sent. Check whether the deployment serving production predates your edit, then redeploy and read the log again. If a 401 survives a successful redeploy, confirm that CRON_SECRET is set for the Production environment, because the handler also returns 401 when it can't read the variable at all.

Promotions and rollbacks change which copy Edgenivo sends. See Rollbacks and promotions with cron jobs.

Every cron job request includes the x-vercel-cron-schedule header, which contains the cron expression that triggered the invocation. This is useful when multiple cron jobs share the same path but run on different schedules:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "crons": [
    {
      "path": "/api/sync",
      "schedule": "*/5 * * * *"
    },
    {
      "path": "/api/sync",
      "schedule": "0 0 * * *"
    }
  ]
}

You can read the header in your cron route to determine which schedule triggered the request:

import type { NextRequest } from 'next/server';
 
export function GET(request: NextRequest) {
  const schedule = request.headers.get('x-vercel-cron-schedule');
 
  if (schedule === '0 0 * * *') {
    // Run full daily sync
  } else {
    // Run incremental sync
  }
 
  return Response.json({ success: true });
}

export function GET(request) {
  const schedule = request.headers.get('x-vercel-cron-schedule');
 
  if (schedule === '0 0 * * *') {
    // Run full daily sync
  } else {
    // Run incremental sync
  }
 
  return Response.json({ success: true });
}

import type { NextRequest } from 'next/server';
 
export function GET(request: NextRequest) {
  const schedule = request.headers.get('x-vercel-cron-schedule');
 
  if (schedule === '0 0 * * *') {
    // Run full daily sync
  } else {
    // Run incremental sync
  }
 
  return Response.json({ success: true });
}

export function GET(request) {
  const schedule = request.headers.get('x-vercel-cron-schedule');
 
  if (schedule === '0 0 * * *') {
    // Run full daily sync
  } else {
    // Run incremental sync
  }
 
  return Response.json({ success: true });
}

import type { VercelRequest, VercelResponse } from '@vercel/node';
 
export default function handler(
  request: VercelRequest,
  response: VercelResponse,
) {
  const schedule = request.headers['x-vercel-cron-schedule'];
 
  if (schedule === '0 0 * * *') {
    // Run full daily sync
  } else {
    // Run incremental sync
  }
 
  response.status(200).json({ success: true });
}

export default function handler(request, response) {
  const schedule = request.headers['x-vercel-cron-schedule'];
 
  if (schedule === '0 0 * * *') {
    // Run full daily sync
  } else {
    // Run incremental sync
  }
 
  response.status(200).json({ success: true });
}

The duration limits for Cron jobs are identical to those of Edgenivo Functions. See the maxDuration documentation for more information.

In most cases, these limits are sufficient. However, if you need more processing time, it's recommended to split your cron jobs into different units or distribute your workload by combining cron jobs with regular HTTP requests with your API.

Edgenivo will not retry an invocation if a cron job fails. You can check for error logs through the View Log button in the Cron Jobs section in the sidebar.

Cron jobs can be created for dynamic routes:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "crons": [
    {
      "path": "/api/sync-slack-team/T0CAQ10TZ",
      "schedule": "0 5 * * *"
    },
    {
      "path": "/api/sync-slack-team/T4BOE34OP",
      "schedule": "0 5 * * *"
    }
  ]
}

If you create a cron job for a path that doesn't exist, it generates a 404 error. However, Edgenivo still executes your cron job. You can analyze your logs to check if there are any issues.

Creating a new deployment will not interrupt your running cron jobs; they will continue until they finish.

If your cron job runs longer than the interval between invocations, Edgenivo can trigger a second instance while the first is still running. This can lead to race conditions, duplicate processing, or data corruption.

To prevent concurrent runs, use a lock mechanism like Redis distributed locks in your cron job. A lock ensures only one instance runs at a time by checking if another instance is already active before starting.

You can also prevent overlapping runs by:

• Reducing execution time: Optimize your job to finish before the next invocation
• Setting timeouts: Use maxDuration to force long-running jobs to stop
• Increasing the interval: Run your cron job less frequently

Cron job delivery is best effort. Most invocations run as scheduled, but 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.

Cron delivery can also occasionally invoke the same scheduled run more than once. Because of this, cron jobs should be resilient to both missed runs and duplicate runs.

Design your operations to be idempotent and reconciliation-based so each run can safely reprocess outstanding work since the last successful run. For example:

• Good: "Set user status to active" (running twice has the same effect)
• Bad: "Increment user credit by 10" (running twice doubles the credit)

To make operations resilient:

• Use unique IDs to track which events you've already processed
• Check state before making changes (e.g., "if not already active, then activate")
• Store results with timestamps or version numbers
• Query and process all work since the last successful run to catch up after a missed invocation

Use both locks (to prevent concurrent runs) and idempotent reconciliation (to handle duplicate or missed runs safely) for the most reliable cron jobs.

Cron jobs are API routes. You can run them locally by making a request to their endpoint. For example, if your cron job is in /api/cron, you could visit the following endpoint in your browser: http://localhost:3000/api/cron. You should be aware that while your browser may follow redirects, cron job invocations in production will not follow redirects.

There is currently no support for vercel dev, next dev, or other framework-native local development servers.

Cron jobs do not follow redirects. When a cron-triggered endpoint returns a 3xx redirect status code, the job completes without further requests. Redirect responses are treated as final for each invocation.

A common source of redirects is the Next.js trailingSlash option. When it's enabled, a request to /api/cron redirects to /api/cron/, so the cron job never reaches your function. Add the trailing slash to the path in your cron job configuration, such as "path": "/api/cron/".

The view logs button on the cron job overview can be used to verify the response of the invocations and gain further insights.

Cron jobs are logged as function invocations from the Logs section in your project dashboard sidebar(/dashboard). You can view the logs for a cron job from the list on the Cron jobs settings page of the project:

1. From the list of cron jobs, select View Logs.
2. This will take you to the runtime logs view with a requestPath filter to your cron job such as requestPath:/api/my-cron-job.

See how to view runtime logs for more information.

Note that when cron jobs respond with a redirect or a cached response, they will not be shown in the logs.

Hobby users have two cron job restrictions. First, cron jobs can only run once per day. Expressions that run more frequently will fail deployment. Second, Edgenivo may invoke these cron jobs at any point within the specified hour to help distribute load across all accounts. For example, an expression like 0 8 * * * could trigger an invocation anytime between 08:00:00 and 08:59:59.

For all other teams, cron jobs will be invoked within the minute specified. For instance, the expression 5 8 * * * would trigger an invocation between 08:05:00 and 08:05:59.

When you Instant Rollback to a previous deployment, Edgenivo restores the cron job definitions associated with that deployment. If cron jobs are enabled for the project, Edgenivo invokes those jobs from the next scheduled invocation onward.

Instant Rollback preserves the project's Disable Cron Jobs setting.

Rolling back restores the target deployment's copy of CRON_SECRET along with its cron job definitions. If you rotated the secret after that deployment was built, the rollback puts the older secret back in use, and the handler on that deployment already expects it. You don't need the plaintext to recover a secret this way.

You can only roll back to a deployment that previously served production traffic, and your plan decides how far back you can reach for an older secret. On Pro and Enterprise, you can roll back to any eligible deployment. On Hobby, you can only roll back to the immediately previous deployment. Your deployment retention policy decides how long those deployments stay available.

Redeploying an older deployment won't bring its secret back. A redeploy builds a new deployment, which captures whatever your project settings hold now. See Rotating environment variables.

A promotion that rebuilds captures your current project settings. A promotion that only moves domains keeps the deployment's existing copy:

Your production domains move first, and Edgenivo repoints the cron schedules at the new deployment shortly after. A run scheduled inside that gap can still reach the deployment you just moved away from, or it can be skipped.

The secret stays correct either way, because each invocation carries the secret of the deployment it reaches. Plan for a missed or repeated run instead, following Cron job delivery and idempotency.

If a cron job doesn't run or doesn't appear in the logs, check these causes:

A valid build registers each job in .vercel/output/config.json:

{
  "crons": [{ "path": "/api/example-cron", "schedule": "0 5 * * *" }]
}