Use cases · Serverless

Serverless cron jobs across Vercel, Lambda, Cloudflare, Netlify and friends

Most serverless platforms ship a built-in scheduler with one big constraint: UTC-only, fixed minimum interval, or coupled to deploys. The spokes here cover the work teams actually do.

About this topic

Serverless

8 itemsUse cases

Vercel Cron is convenient if you're on Pro and one UTC schedule is enough. Cloudflare Workers Cron Triggers floor at 1 minute and stay inside the Cloudflare estate. AWS Lambda needs EventBridge plus IAM. Firebase scheduling needs the Blaze plan. Netlify Scheduled Functions cap at 30-second runtimes. Each platform has a sensible answer for the simple case and runs out of headroom the moment you need per-schedule timezones, multiple environments, or schedules that don't ride your deploy cadence.

The spokes here are the external cron patterns for each: hit the Vercel function URL, the .run.app URL, the Lambda Function URL, the .workers.dev route, the Netlify function, the Firebase HTTPS function, the Supabase Edge Function. Same pattern across all of them: HTTP target, custom headers (a shared secret, a JWT, an OIDC token), per-schedule timezone, retries, failure alerts to Slack, Discord, Telegram, email or webhook. One dashboard across stacks.

Use cases on Serverless

8 items

Related on Crontap

The same Serverless topic, from other angles.

FAQ

Common questions on Serverless

If Vercel Cron already runs my schedule, why move?
If one UTC schedule on a Vercel-hosted app is your whole need, stay. Move when you want a per-schedule timezone (Vercel Cron is UTC-only), sub-hour cadence on Hobby, multiple environments (preview vs prod) on the same plan, or a single dashboard across Vercel and non-Vercel work.
How do I authenticate the call from Crontap into my serverless endpoint?
Add a custom header on the Crontap schedule (X-Crontap-Token: <secret>) and check it inside the function. For Cloud Run or Cloud Functions you can also issue an OIDC token in the header. The schedule UI accepts arbitrary headers per schedule, so the same pattern works for AWS, Cloudflare, Vercel, Netlify, Firebase, Supabase.
Cold starts. Will the first invocation after idle be slow?
Sometimes, depending on platform. The cache-warming spoke is the explicit pattern for keeping serverless edges warm: schedule a low-priority warmup ping a few minutes before traffic peaks. Or just accept the first cold start of the day and have Crontap surface it as a slower duration in the run log so you spot it.
Does Crontap care which platform I'm on?
No. Every spoke here is the same shape: an HTTPS URL on a cron, in your timezone, with retries and alerts. Migrate between Vercel, Cloudflare, AWS and the schedule keeps working. That's most of the appeal of running cron outside the platform.

More from Crontap

Topics across the site.

Every topic Crontap covers, in one row. Each one has its own page on the use cases surface.

Ready to fix it?

Point Crontap at any URL. Pick any cron. Done.

WordPress, Shopify, Railway, Cloud Run, Vercel, HubSpot, Ghost, your own box. If it answers HTTP, Crontap can drive it on a clock you can read, in the timezone that actually matters, and page you when something breaks.

Free forever tier ・ No credit card required

GET

/wp-cron.php?doing_wp_cron=1

Running
Your next schedule

Schedule

"every 5 minutes"

Next

in 23s