Cloudflare cron to discord

Cloudflare Cron → Discord Webhook

Send scheduled notifications from a Cloudflare Worker Cron Trigger to a Discord channel, with an architecture that's safe to extend into real domain logic later.

Prerequisite: a working Workers skeleton with scheduled handler wired (see the cloudflare-workers-deploy-skeleton skill).

When to use

• Daily / hourly / weekly Discord notifications (reminders, summaries, health checks)
• Any scheduled outbound message from Workers to any webhook-style recipient (Discord is the example; the architecture transfers to Slack, Teams, etc. by swapping the HTTP contract)
• As a walking skeleton before real domain logic is ready — skeleton message first, then replace the pure builder with real logic later

Do not use for:

• High-frequency fanout (Cron trigger is limited to 1-minute granularity)
• Bidirectional Discord interactions (use Discord Bot with Interactions, not webhooks)
• Anything requiring Cron retry semantics (Workers Cron is fire-once-per-schedule; implement retries on top yourself)

The architecture: pure → boundary

scheduled(event, env)
  └─ runScheduled(event, env)
       ├─ buildMessage(now: Date): Payload        ← pure function
       └─ postToDiscord(url, payload): Promise<void>  ← boundary, never throws

Two rules:

1. The builder is pure. No I/O, no env, no clock reads (take now as a parameter). This makes it trivially unit-testable and trivially replaceable (Phase N skeleton message → Phase N+1 domain logic).
2. The sender never throws. All fetch failures are console.error'd and swallowed. Reasons:
   • Cron runs on a schedule. A single failed notification should not prevent the next one.
   • There's no retry semantics to leverage anyway.
   • Throwing from a scheduled handler doesn't help the user — it just shows up as an opaque exception in the Dashboard.

Core deliverables

1. worker/time.ts — pure UTC→JST conversion (or your timezone of choice). Environment-TZ-independent using getUTC*() methods
2. worker/discord.ts — buildSkeletonMessage(now) (pure) + postToDiscord(url, payload) (boundary, throw-less)
3. worker/cron.ts — wire builder → sender
4. worker/types.ts — add DISCORD_WEBHOOK_URL: string to Bindings
5. vitest setup — vitest.config.ts + ten tests (6 time + 4 discord)
6. Production Discord Webhook created and installed via wrangler secret put DISCORD_WEBHOOK_URL
7. Development Discord Webhook installed in .dev.vars (separate channel from prod)

See references/implementation.md for the full source code, ready to paste in.

Dev/prod discipline: webhook naming

Always create two webhooks in separate Discord channels:

• <project-name> (dev) → channel #<project>-dev
• <project-name> (prod) → channel #<project> (or wherever prod lives)

Why the naming matters: webhook values (https://discord.com/api/webhooks/<id>/<token>) are not visible after installation (wrangler secret list shows names only). If you accidentally put the dev URL into the prod secret (or vice versa), the only way to detect it is to look at where messages actually arrive.

If a message posted by "routine-tasks (dev)" shows up in the prod channel, you've cross-contaminated. Naming the webhooks identifiably makes this detectable in 30 seconds.

Full operational workflow in references/operations.md.

The vitest testing pattern

For the pure builder: standard table-driven tests with known UTC inputs and expected JST output strings.

For the boundary sender: vi.spyOn(globalThis, "fetch") to mock fetch, then assert:

• Success path: fetch is called with the right URL and method
• Non-2xx: does NOT throw, logs to console.error
• Fetch rejection: does NOT throw, logs to console.error

Environment must be "node" (not "jsdom"), and the vitest.config.ts must be separate from vite.config.ts — loading the @cloudflare/vite-plugin into the test runner causes unhelpful dev-server side-effects.

Full test code in references/testing.md.

Production setup flow

High-level; detailed commands in references/operations.md:

1. User: Create two Discord webhooks with the dev/prod naming discipline above
2. User: wrangler secret put DISCORD_WEBHOOK_URL and paste the prod URL
3. User: Copy .dev.vars.example → .dev.vars, paste the dev URL
4. Agent: Copy time.ts / discord.ts / vitest files from references, wire cron.ts
5. Agent: pnpm install → pnpm check → pnpm test (10/10 green)
6. Agent: Commit → push → user merges → auto-deploy
7. Validate prod: wrangler tail shows [cron] fired at ... at scheduled time, Discord prod channel receives [<project>] cron fired at <JST> (skeleton) message

The /__scheduled dev caveat

@cloudflare/[email protected] does not implement /__scheduled?cron=<expr> for local Cron testing — requests fall back to the SPA HTML. 1.x fixes it but requires wrangler@^4.

Your options for local Cron verification:

1. Skip local Cron testing — rely on vitest mocks + production verification. This is the practical default unless you're iterating heavily on Cron schedule changes
2. Bump @cloudflare/vite-plugin@^1.x + wrangler@^4 simultaneously — major version jump, treat as its own task
3. Use Cloudflare Dashboard → Triggers → "Send event" / "Run now" button for on-demand prod testing (doesn't help local, but enables fast prod verification)

Full tradeoffs in references/operations.md.

Diagnosing "prod Discord isn't receiving"

When the cron fires but messages don't land, work the symptom matrix in references/operations.md:

Local dev ch	Prod ch	Likely cause
✓ arrives	✗ nothing	Prod secret wrong, or deploy not reflected yet, or Cron not firing
✗ nothing	✓ arrives	.dev.vars missing, or /__scheduled not routed (skip path)
✗ nothing	✗ nothing	Code-level issue (cron.ts / discord.ts implementation) OR webhook URL itself invalid
Dev msg in prod ch	—	.dev.vars has prod URL (swap fix + rotate)
Prod msg in dev ch	—	Prod secret has dev URL (swap fix + rotate)

Detailed diagnostic flow in references/operations.md — including Dashboard Observability setup, wrangler deployments list-based reflection check, and webhook rotation procedure with reflection-verification.

Progressive disclosure: when to replace skeleton

When real domain logic arrives (e.g., "notify about unfinished tasks from D1"):

1. Keep the signatures of buildMessage and postToDiscord stable. This is the whole point of the boundary: you don't rewire Cron to swap the logic
2. Replace buildSkeletonMessage(now) with buildNotificationMessage(tasks: Task[], now: Date) — still pure
3. Update discord.test.ts to cover the new builder inputs (table-driven: (tasks, now) → expected payload)
4. Update cron.ts to query D1 first, then feed results to the builder

The boundary (postToDiscord) stays exactly the same. The only thing that changes is what's upstream of it.

Scope boundary

This skill does NOT cover:

• The underlying Workers skeleton (wrangler.jsonc, GH Actions, D1) — see cloudflare-workers-deploy-skeleton
• Replacing skeleton logic with real domain rules — that's a project-phase decision; the boundary is designed to make it easy
• Discord embeds, mentions, reaction-based interactions — webhooks support them (add embeds / components fields in the payload) but skeleton uses content only
• Non-Discord recipients — the architecture ports to Slack / Teams / generic HTTP recipients; only the payload shape changes
• neverthrow / Result-type error handling — deferred; skeleton uses try/catch with console.error for simplicity

References

• implementation.md — full source of time.ts, discord.ts, cron.ts, types.ts addition
• testing.md — vitest.config.ts, time.test.ts, discord.test.ts with fetch-mock pattern
• operations.md — Discord webhook creation steps, dev/prod secret workflow, symptom matrix, diagnostic flow, rotation procedure