2026-06-23 · 6 min read · Rahul Chitturi
- cron
- serverless
- debugging
A cron expression that looks obvious in a ticket can run at the wrong local time once it reaches a serverless platform. Many schedulers use UTC by default, some support named timezones, and daylight saving changes can skip or duplicate business-hour jobs.
Treat scheduling as production data. Validate the next run times, the timezone contract, and the retry behavior before the first real customer-impacting execution.
Start with the scheduler timezone
Do not assume the dashboard timezone matches the runtime timezone. Read the platform documentation and write the intended timezone next to the cron expression in code or deployment config. If the business requirement is local time, test dates around daylight saving boundaries.
- Record whether the expression is evaluated in UTC or a named timezone
- Generate the next several run times before deploy
- Check month-end and weekday-only schedules explicitly
- Avoid ambiguous local times during daylight saving transitions
Plan for overlap and retries
Serverless jobs may retry after failures or overlap when the previous run takes longer than expected. Timezone bugs become more painful when the job is not idempotent. Use run IDs, locks, or input windows so repeated execution does not double-charge, resend, or delete data twice.
Log timestamps that humans can compare
Logs should include both the scheduled timestamp and the actual start time in UTC. If product teams reason in a local timezone, add a derived display time in dashboards, but keep UTC as the source of truth for debugging.
- scheduled_for: the window the job intended to process
- started_at: when the platform invoked the function
- completed_at: when work finished
- attempt: retry number or dedupe key
A Flashman workflow
Use the cron parser to preview the next runs, convert timestamps when comparing logs, and format JSON scheduler payloads from the platform. If staging and production disagree, diff the deployed cron expression and environment config before changing job logic.
The safest schedule is one your team can explain from the expression, the generated run list, and the logs. Validate all three before trusting a nightly job with production state.