Cron Parser for Serverless Scheduled Functions How to Configure AWS Lambda Cloudflare Workers and Vercel Cron Jobs

You configure a scheduled function on AWS Lambda. The function should run every 15 minutes, Monday through Friday, between 9 AM and 5 PM. You write the cron expression: */15 9-17 * * 1-5. You deploy. The function runs: every 15 minutes, every day, 24 hours a day. You wake up on Saturday to a $200 AWS bill. The cron expression was wrong. */15 9-17 * * 1-5 means: every 15 minutes, during hours 9-17, every day of the month, every month, Monday through Friday. The hours 9-17 restriction works. The Monday-Friday restriction works. But the function still ran on Saturday — because you did not test the expression before deploying.

A cron parser validates your expression and shows the next execution times before you deploy. "At 09:00 AM, every 15 minutes, Monday through Friday" — plus the next 10 execution times. You verify the times. You deploy. The function runs correctly. No $200 surprise. Here is the serverless cron configuration guide.

Serverless Cron: How Each Platform Handles Scheduled Functions

AWS Lambda (EventBridge Scheduler): Uses standard 5-field cron expressions. Rate-based scheduling is also available: rate(15 minutes) instead of */15 * * * *. Rate expressions are simpler but less flexible — you cannot specify specific hours or days. Cron expressions are more flexible but more error-prone. The cron parser is the safety check.

Cloudflare Workers (Cron Triggers): Uses 5-field cron expressions. Cloudflare's cron implementation is slightly different from standard cron — test your expression with the cron parser before deploying. Cloudflare also limits cron trigger frequency on the free plan (typically minimum 1-hour intervals).

Vercel Cron Jobs: Uses 5-field cron expressions. Vercel's cron syntax is standard. The free plan allows 1 cron job per project. Paid plans allow more. Vercel also displays the next execution time in the dashboard — but only after deployment. The cron parser shows the next execution times before deployment.

GitHub Actions (schedule trigger): Uses POSIX cron syntax (5 fields). GitHub Actions cron jobs run on UTC time — not your local timezone. A cron expression 0 9 * * 1-5 runs at 9:00 AM UTC, not 9:00 AM your time. The timezone offset is the most common GitHub Actions cron mistake. The cron parser shows times in your local timezone. Adjust for UTC when writing GitHub Actions cron expressions.

Common Serverless Cron Mistakes

Timezone confusion: Most serverless cron implementations use UTC. Your cron expression is evaluated in UTC. 9 AM in your cron expression is 9 AM UTC — which might be 2 AM, 4 AM, or 5 PM your time, depending on your timezone. The cron parser shows the next execution times. Adjust the hours in your expression to match your local timezone.

Day-of-month vs day-of-week confusion: When both day-of-month and day-of-week are specified (not *), the cron job runs when either condition matches. 0 0 1 * 1 runs at midnight on the 1st of every month AND every Monday — not just "Monday the 1st." The cron parser shows the next execution times. The confusion is visible in the times before deployment.

Step values producing unexpected patterns: */7 * * * * means "every 7 minutes" — but starting from minute 0, so at 0, 7, 14, 21, 28, 35, 42, 49, 56. Not every 7 minutes from now. The cron parser shows the specific minutes. The pattern is visible before deployment.

Validate your cron expressions at cron parser — before deploying, before the $200 bill, before the 3 AM production incident.