cron-and-scheduled-jobslisted

# Cron & Scheduled Jobs Two mechanisms run recurring work in this stack, and they put the *schedule* in two very different places. Knowing which one you're in tells you where the schedule lives and what owns the recurrence: 1. **Kubernetes CronJob** — the cluster's `CronJob` controller is the scheduler. It fires a fresh pod on the schedule; the pod runs the **same service image** booted in a one-shot `MODE=cron` that executes a single named job from a Python registry and exits. The schedule lives in **Helm values**, never in the app. 2. **Temporal Schedule** — the **Temporal server** is the durable scheduler. A `Schedule` object fires a workflow on a cron expression or interval; a missed window, catch-up, pause, and backfill are all first-class. The schedule lives in **a registration step** (run once / idempotently on deploy). > Companion skills: `temporal-config-driven` (workflow/activity/worker mechanics, retries, idempotency, > and the deeper schedule-registration reference — this skill cross-links it rather than repeating it), > `containerization-and-deployment` (the `MODE`-dispatch entrypoint and Helm packaging), > `kubernetes-workload-hardening` (securityContext/NetworkPolicy for the CronJob pod), and > `observability-and-logging` (the cron execution metric). ## When to use - Adding a **periodic / scheduled job** to a service and deciding where the schedule belongs - Wiring a **`MODE=cron` entrypoint** and registering a job in the **Python cron regis