Cron schedules

Defined in wrangler.jsonc triggers.crons. Two schedules currently.

0 6 * * * — daily 06:00Z (midnight MT)

Spawns DailyFlagSyncWorkflow which:

1. Fetches all bookings within 365 days
2. For each, calls ensureBookingFlagWorkflow
3. New bookings get a workflow instance; existing ones get respawned (their workflow phases re-evaluate cleanly via idempotency)

The cold-start safety net. Most bookings get a workflow via the booking-event push webhook within seconds — this cron handles anything that slipped through.

*/15 * * * * — every 15 minutes

Runs three sweeps in sequence:

1. runBeds24MessageReconciliation — verifies our outbound Beds24 thread messages landed (fetches /bookings/messages for unverified bookings, matches by message-id, marks delivered)
2. runDeliveryWatchdog — alerts Bill via SMS for any outbound_log row >10min old with no delivery confirmation
3. runSoftBounceSweep — checks for recipients with ≥3 temporary failures in 24h, alerts Bill once per 24h per recipient

Order matters: reconciliation FIRST so Beds24 thread sends don’t trigger watchdog false-positives.

What’s NOT a cron

Anything per-booking is a workflow step, not a cron:

• Arrival-day Bill emails — workflow runArrivalDayBillEmail
• Departure-day Bill emails — workflow runDepartureDayBillEmail
• 3pm still-dirty check — workflow runStillDirtyCheck
• A+1 check-in form chase — workflow runArrivalPlusOneCheckinChase
• All cleaner touchpoints

This follows the design principle: per-resource lifecycle stays in workflows; only account-wide sweeps use cron.

Source

• wrangler.jsonc — cron triggers
• src/index.ts — scheduled handler dispatches based on event.cron