In brief
Local Explorer can now invoke scheduled Worker handlers on demand, giving teams a practical way to test time-based jobs before deployment.
What changed
On 17 October 2026, Cloudflare added Cron Trigger testing to Local Explorer. Developers can invoke a Worker’s scheduled handler during local development, choose configured or ad hoc cron expressions, set a test time and inspect the result.
These local presets do not change deployed schedules or configuration files. Cloudflare also explicitly notes that local development does not automatically run cron schedules. This is an on-demand testing feature, not a production scheduling change.
Why scheduled business jobs need their own tests
Daily summaries, periodic reminders and reconciliation reports can appear simple because their trigger is a time rather than a user click. The difficult cases often sit around that trigger: an empty source, a repeated run or a job that starts after its intended window.
Our recommendation is to define the expected business result before testing the schedule. For a report, specify which records belong in the period and what should happen if no records qualify.
A useful acceptance test
Use a separate test dataset and avoid sending real customer messages during rehearsal. Run the same sample twice and compare the output, then try a sample with missing or late data.
- Verify the reporting period and timezone separately from the job’s execution time.
- Check that repeating a run does not duplicate a consequential action.
- Make a source unavailable and confirm the failure is visible.
- Test the boundary between two reporting periods.
- Confirm who investigates a failed production run.
Local success is only one checkpoint
After local tests pass, separately verify the deployed trigger, environment configuration and actual production observation. A correct handler does not prove that the intended schedule has been deployed.
For SME owners commissioning automation, ask for evidence of both: a controlled test of the business logic and confirmation that the live job ran as expected. This keeps “it should run tomorrow” separate from “we verified the result”.
