Local Explorer has been extended to allow a one‑off invocation of a Worker’s scheduled() handler directly from a local development session. By exposing a UI and an API that accept a cron expression and optional timestamp, engineers can test time‑driven code paths without crafting request URLs or altering deployed cron configurations.
One‑off Cron Invocation via Browser
Start a local dev server with cf dev, wrangler dev, or the Cloudflare Vite plugin, then navigate to /cdn-cgi/local/explorer and choose the Cron Triggers tab. The interface lets you:
- Run any cron expression already defined in the Worker’s configuration.
- Compose ad‑hoc expressions for quick edge‑case testing.
- Save reusable scheduled timestamps for repeated runs.
- View the handler’s result and the
noRetry()flag status.
All browser‑side presets remain local; they never modify cloudflare.config.ts, Wrangler settings, or the deployed schedule. Local development does not automatically execute cron schedules, preserving a deterministic test environment.
API Access for Automation and AI Agents
The same capability is exposed through a REST endpoint, enabling scripts, CI pipelines, or AI‑driven assistants to trigger scheduled runs programmatically. The request must specify the exact Worker name and include a JSON body with cron and optional scheduled_time fields. An example targeting a dev server on port 8787 looks like:
curl -X POST \
"http://localhost:8787/cdn-cgi/local/explorer/api/local/scheduled?worker=my-worker" \
-H "Content-Type: application/json" \
--data '{"cron":"0 * * * *","scheduled_time":1745856238000}'
Replace the port with the one used by your local environment (e.g., 5173 for Vite).
Operational and Observability Impact
When the dev session has Observability enabled, full logs and trace data for the one‑off invocation are attached to the same session that owns the Worker. This provides immediate feedback on execution latency, error handling, and the effect of noRetry(). Because the operation is confined to the local process, there is no risk of unintentionally triggering production cron jobs or altering live schedules.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Engineers can now validate cron‑driven logic in isolation, integrate the API call into automated test suites, and rely on built‑in observability for rapid debugging. The change does not introduce new security boundaries, but practitioners should ensure that Observability remains enabled in the dev session to capture trace data. Future evaluation should monitor any extensions to the API that might affect CI integration or policy enforcement.
