Temporal schedules to replace cron jobs

The cutover is where duplicate runs happen, so the plan has to guarantee that exactly one trigger is active for each job at any moment. Start with an inventory of every crontab entry on every host that runs recurring work, plus every Temporal Cron Job already defined in your namespaces. For each item, record the command or workflow, the schedule expression, the time zone the host uses, the account it runs as, the systems it writes to or calls, the owner, and the alert that fires on failure. Then map each job to a Temporal schedule specification and choose an overlap policy. A job that can run longer than its interval needs an explicit decision about what happens to the next start, and that decision should be written into the migration record.

Run the new schedule alongside the old trigger for a defined number of cycles before cutover, but only if the workflow can run during that period without causing side effects. Many teams add a mode flag so the workflow records its intended actions and skips external writes. Compare the Temporal execution history with the cron logs for each cycle, checking that start times, inputs and outcomes match. Agree the acceptance criteria with the job owners before the parallel run starts, including how many consecutive matching cycles count as verified. Only after verification should you comment out the crontab line or pause the old Temporal Cron Job. Keep the original definition in version control so the rollback path is a single change, and record who approved the switch and when.

Time zones are the most common source of subtle drift. Cron evaluates expressions in the host's local time, while a Temporal schedule specification carries its own time zone setting, so an entry that looked correct in a crontab can fire at a different instant after migration if the zones differ. Confirm the time zone each job should follow, then write it explicitly in every spec. Also test the behavior around daylight saving transitions in both directions. Ask the platform team to document what the schedule does with a local time that is skipped in spring and with one that occurs twice in autumn, then compare that with what your existing crontab does on the same hosts. Jobs tied to business cutoffs may need to run in UTC instead, which is a policy question for the business owner to settle before cutover.

Idempotency limits the damage when two triggers overlap, a worker restarts mid-run, or an operator re-enables a paused schedule. Derive a deterministic key for each run from the job name and its scheduled time, so every retry sees the same identity. Before any side effect, the workflow checks whether that key has already been processed in the system of record, and it passes the same key to external APIs that accept idempotency keys. Illustrative example: a nightly export keyed by business date writes a file named for that date, so a second run replaces the same file with identical content and does not create a second posting. Treat the key design as a review item for each job, because a key built from execution time will not protect against duplicates.

Before you retire any old job, test the failure and restart paths in a non-production namespace using the same worker build you plan to deploy. Stop a worker in the middle of a run and confirm the run resumes without repeating completed side effects. Force an activity to fail until its retry policy is exhausted, then check that the alert fires and that the next scheduled run behaves as the overlap policy specifies. Pause and unpause the schedule, and simulate an outage long enough to create missed runs, then confirm how catch-up runs interact with your idempotency keys. Keep a short written record of each test, its expected result and its actual result. Retire the cron entry only when every path has passed and the job owner has signed off on the results.

Once recurring jobs run as Temporal Schedules, the operational risk shifts from a crontab on one host to a registry of schedule objects spread across namespaces. The first task is an inventory: list every schedule ID, its namespace, its spec type (interval or calendar), its overlap policy, its paused state, and the workflow type it starts. Adopt a naming convention that encodes the owning team, the business purpose and the environment, for example billing-invoice-export-prod, so that a schedule found in a search can be traced to an owner without opening the code. Store the inventory in your configuration repository and generate it from the server rather than from memory, because schedules created through the UI or ad hoc CLI calls are the ones most likely to drift from what the team believes is running.

Monitoring needs four signals. Track run creation, meaning whether each schedule is starting workflow executions at the frequency its spec implies. Track missed runs, which Temporal records when a run is skipped or delayed, so the catch-up behavior you chose during design is visible rather than silent. Track workflow failures for every workflow a schedule starts, since a schedule that starts successfully but fails every run looks healthy at the scheduler level. Finally, alert on paused schedules. A pause is a deliberate control, but a pause left in place after an incident is an outage nobody is watching. Route paused-schedule alerts to the owning team with an expiry or review date, and confirm with your monitoring stack which Temporal metrics and visibility queries your version exposes for these signals before you build dashboards on them.

Capacity grows with run frequency in two places. Worker capacity grows because every run consumes task slots, worker memory and downstream calls, so a schedule that moves from hourly to every minute multiplies that load even when each run is cheap. Visibility store load grows because every run creates workflow executions that the visibility store indexes and that operators search. High-frequency schedules are therefore the main reason visibility sizing changes. Temporal documents Elasticsearch or OpenSearch as the recommended advanced visibility store for anything beyond a few workflow executions, and the choice of store shapes how quickly operators can find a schedule's recent runs or filter failures. Test your query patterns against the store you plan to run, not against a development setup.

Confirm the schedule limits for your server version before you commit to a design. Check the documented maximum number of schedules per namespace, the number of actions a schedule may buffer, and any limits on spec complexity or history size for schedules, because these limits change between releases and determine whether one namespace can hold your whole inventory. Also confirm how your version reports missed-run and buffer behavior in visibility, and whether the Temporal Cloud pricing model would change the cost of high-frequency schedules if you later move the workload. Record the answers in the inventory so the next upgrade review checks them again.