SaaS Scheduled Jobs: Define Missed Runs, Overlap, and Clock Changes

A daily report scheduled for nine o’clock sounds straightforward until the service is unavailable at nine, yesterday’s run is still active, or a customer’s local clock changes. The schedule describes an intention. The product still needs rules for deciding whether to start work, how much missed work to recover, and what to tell a customer when no result appears.

These decisions belong in the feature specification before the scheduler is selected. A reminder, a billing aggregation, and a nightly search-index refresh can share the same infrastructure while requiring different behavior. Defining their contracts explicitly prevents an implementation default from becoming an accidental promise about customer data or repeated side effects.

Name the logical occurrence

Represent each planned occurrence independently from its execution attempts. A useful record includes the schedule identifier and version, intended time, time zone, input boundary, and a stable occurrence identifier. Attempts then have their own start, finish, outcome, and failure information. Retrying the same intended report should not look like a new scheduled event.

For a hypothetical weekly workspace report, the occurrence might refer to the reporting week ending on a specific local date. Its first execution can fail and a later attempt can succeed without producing two weekly reports. Decide whether retrying uses the originally defined input snapshot or current data. Both can be valid, but they answer different questions and need different labels.

Choose a missed-run policy by consequence

There are several reasonable recovery policies. A refresh may skip missed occurrences and run once with current data. A ledger process may need to process every missing interval in order. A time-sensitive reminder may be useless after its deadline and should be recorded as skipped. A bounded catch-up policy can recover a limited window while flagging older gaps for review.

Write the chosen policy beside the schedule configuration. Include the maximum age of useful work, the recovery limit, and who owns an exceeded limit. Avoid an unlimited catch-up loop that starts hundreds of obsolete actions after a long outage. Conversely, do not silently collapse historical processing when each interval has a distinct business meaning. The correct choice comes from the output’s purpose.

Expose recovery as a decision, not a mystery. If a daily digest was skipped because it was already stale, display that reason in the run history. If only the latest digest will be generated after recovery, say so in the feature’s operational documentation. Customers should not need to infer the policy from how many emails arrive after an incident.

Define overlap separately from retries

A schedule can fire while an earlier occurrence is still running. Choose whether to permit concurrency, skip the new occurrence, queue it, or replace the old work where cancellation is safe. A long-running data export may justify queueing. A periodic cache refresh may justify keeping one active worker and recording that another refresh request was coalesced.

Be precise about the scope of exclusion. A lock for one schedule does not necessarily prevent a manual action or another schedule from touching the same resource. If several paths update the same report or account, coordinate at that resource boundary. Cancellation also needs checkpoints; marking a run replaced does not undo an external message that it already sent.

Treat the scheduler’s guarantees as an input

For example, the official Kubernetes CronJob documentation explains that scheduling is approximate and circumstances can produce two jobs or no job. It therefore recommends idempotent jobs. Its concurrency policy applies to jobs created by the same CronJob, which is narrower than a universal application lock.

This is a useful reminder to review the actual scheduler documentation rather than assume exactly-once execution. Record the guarantees and limitations relevant to the installed version. Application-level safeguards remain necessary when a duplicate trigger could produce a duplicate invoice, notification, or export. Infrastructure configuration and business-level completion are different layers of evidence.

Resolve local-clock ambiguity deliberately

Ask whether a schedule means an elapsed interval or a wall-clock time in a named time zone. Every twenty-four hours and every day at nine in the customer’s location are different intentions. Store the named zone for a local-time schedule rather than only the current numeric offset, and document how changes to the schedule or zone take effect.

Local clock changes can make some wall times occur twice or not at all. Choose a policy for those cases and test it with your scheduling library and time-zone data. For instance, a product might choose one occurrence on a repeated local date and skip a nonexistent time, or deliberately move it to a defined alternative. Do not leave that decision to an unreviewed default.

Show upcoming executions in the customer’s selected zone and include an unambiguous timestamp in operational records. When editing a schedule, preview several future occurrences around relevant clock changes. Preserve the version used for already-created occurrences so an administrator can explain why an earlier run followed the previous rule rather than today’s settings.

Protect effects at the application boundary

Use the stable occurrence identifier to deduplicate work where appropriate. Claiming an occurrence and creating an output should have a design that survives a worker crash between steps. Depending on the storage and external service, that may involve transactional records, an outbox, or a provider-supported idempotency key. Choose mechanisms that cover the actual failure boundary instead of merely adding a lock around startup.

A lease can help detect abandoned execution, but expiration does not prove the old worker stopped. Design workers so a stale owner cannot keep committing results after a replacement takes over. For external side effects, reconcile the provider’s result before retrying an uncertain response. Record partial completion where an operation has several independently observable effects.

Make the run history useful to operators

Track intended time, actual start, completion, duration, attempt number, and result separately. Distinguish skipped, waiting, running, failed, partially completed, and completed states when those distinctions affect recovery. A successful process exit is insufficient if the expected artifact was never created. Verify the business result, such as a report identifier or a confirmed destination receipt.

Use alerts that lead to a decision: an occurrence exceeded its deadline, a lease needs reconciliation, or catch-up limits were reached. AI can help group recurring failure explanations or draft an incident summary from recorded evidence. It should not invent a successful run to fill a gap or automatically replay customer-facing actions whose safety is uncertain.

Conclusion

Scheduled work becomes dependable when its behavior is explicit at the edges. Define the logical occurrence, missed-run policy, overlap rules, time-zone semantics, and evidence of completion. Then test crashes, delays, duplicates, and clock changes against that contract. The result is a schedule that customers can understand and operators can recover without guessing which actions have already happened.