Vercel Cron Not Working? The Fix for Hobby Plans

Why is my Vercel Cron job not working?

If you have configured a Vercel Cron job in your vercel.json and it refuses to trigger, check your plan limits first. The Vercel Hobby plan enforces a strict limit: cron jobs can only run once every 24 hours. Any attempt to set a more frequent schedule, such as every hour, will result in the job being ignored or failing to enqueue.

This is not a bug in your code, but a platform constraint. If you expect your task to run every few minutes or even every few hours, the native Vercel cron feature will not suffice for your tier. You need an external scheduler to act as a heartbeat for your application.

Understanding this limitation requires recognizing that Vercel manages the scheduling infrastructure for you on higher tiers, but places a shared capacity constraint on the Hobby tier. When you define a cron expression in your configuration file, the platform validates that frequency against your account status. If the expression frequency exceeds once per day, the Vercel deployment engine silently discards the instruction rather than throwing an explicit error during the build phase.

This behavior often leads to confusion because the code itself is syntactically valid and works perfectly if invoked manually. Developers frequently check their function logs only to find no invocation record, which leads them to search for network issues, cold starts, or environment variable configuration errors. In reality, the job simply never enters the queue because the platform-level validator intercepts the scheduling instruction and rejects it for being outside the permissible bounds of the Hobby tier.

How to use cron-job.org with Vercel

The most reliable workaround for the Hobby plan limitation is to use an external service like cron-job.org. Instead of relying on Vercel to manage the schedule, you configure the external service to send a standard HTTP GET or POST request to your Vercel API route at your desired frequency.

This approach turns your background task into a standard API endpoint. Because Vercel functions are publicly accessible by default, you must implement authentication to ensure only your cron provider can trigger the logic.

To begin this process, you first create an API route within your application. If you are using Next.js, this typically involves creating a file inside the app/api directory. This route will contain the heavy lifting—the data synchronization, database cleanup, or email dispatching logic you previously hoped to run via the native cron feature.

Once the endpoint is ready and deployed, you register it with cron-job.org. You provide the full URL of your endpoint, choose a frequency, and ensure that the HTTP method used by the external service matches the method expected by your route handler. For most cases, a simple GET request is sufficient, provided you have added the necessary security headers to prevent public execution.

How to secure your API routes

When your API route is exposed to the internet for a scheduler, anyone who knows the URL can trigger it. You must secure this route by verifying a secret key in the request headers.

Create a secret in your Vercel environment variables, such as CRON_SECRET. In your route handler, check for this header before executing your logic.

The verification process is straightforward: your cron provider, such as cron-job.org, offers a section in its dashboard where you can define custom headers. You should add a header, for example, Authorization, with a value matching your Bearer <CRON_SECRET> string. Your API route then performs a direct comparison between this incoming header and the process.env.CRON_SECRET value defined in your Vercel project settings.

This mechanism acts as a simple shared secret. Because the secret is never exposed in the client-side code, it remains private within your serverless environment. If a request arrives without the correct header, your function terminates early, returning a 401 status code, ensuring that unauthorized parties cannot drain your compute usage or execute malicious tasks on your server.

import { NextResponse } from 'next/server';

export async function GET(request: Request) {
  const authHeader = request.headers.get('Authorization');
  
  if (authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
    return new NextResponse('Unauthorized', { status: 401 });
  }

  // Run your logic here
  return NextResponse.json({ success: true });
}

Vercel Native vs External Scheduling

Choosing the right scheduling strategy depends on your application tier and complexity. The following table breaks down the differences between relying on Vercel's built-in system versus an external trigger.

If your tasks are resource-intensive, be aware that Vercel Hobby functions have a timeout limit, which often requires moving heavy lifting to a specialized background worker.

The primary advantage of the Vercel native system is convenience and tighter platform integration. The system automatically handles retries and logging in a unified dashboard. However, the limitation of the Hobby plan forces a choice between upgrading to a Pro account or shifting toward an external-managed trigger. External triggers offer significantly more flexibility regarding execution frequency and are often free for personal hobby projects, provided you manage the endpoint security yourself.

Beyond frequency and cost, consider visibility. Vercel's native logs are very helpful when something goes wrong with an internal cron, whereas external triggers require you to check the external service's history for successful requests and your Vercel logs for successful execution. Aligning these two systems is necessary for efficient debugging when a scheduled job fails.

Common gotchas and trade-offs

Even with an external scheduler, your task might fail if it hits serverless execution limits. Vercel Hobby functions are limited to a 10-second timeout. If your task involves heavy data processing, scraping, or AI calls, it will crash before completion.

If you face timeout issues, do not use await on the entire process. Instead, offload the work to a queue system or a dedicated VPS. You can find more details on handling timeouts in my guide on Fixing Vercel Server Function Timeout: A Practical Guide.

Another frequent hurdle is the memory usage of the function. Serverless environments are often constrained in memory, meaning operations that load large datasets into memory will crash before the time-based timeout occurs. Monitoring your function logs for OOM (Out of Memory) errors is just as important as monitoring execution time.

Finally, ensure that your cron triggers are not overlapping. If your external scheduler is set to run every minute, but your process takes 90 seconds to finish, you will eventually have multiple instances of the function running simultaneously. This can lead to database locking, duplicate entries, or API rate-limiting if the downstream services you are calling become overwhelmed by concurrent requests from your serverless function.

Frequently asked questions

Sources & further reading

• Usage & Pricing for Cron Jobs
• Cron Jobs