# Measure scheduled work against its intended occurrence

A job's eventual success does not show that it ran at the right business time. Track due occurrences, delay and duplicate effects separately.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Define the due population

Generate or identify the occurrences required by the schedule's local rule, zone and version. Apply the documented gap, overlap and missed-work policies.

Do not use only jobs that happened to be enqueued as the denominator. A scheduler defect can fail to create the job entirely.

Keep an independent expectation for important recurring work, with a scale appropriate to the system.

## Measure execution delay

Compare actual start or completion with the resolved intended instant according to the service promise. Some tasks care about starting on time, while others care about a result being ready by a deadline.

Separate scheduler delay, queue delay and processing duration. The breakdown helps identify whether the issue is time resolution or downstream capacity.

Record late completion without rewriting it as an on-time result after recovery.

## Count missed and duplicate occurrences

Track occurrences with no accepted execution, those deliberately skipped under policy and those superseded by an edit. These are different outcomes.

Use the occurrence identity to detect repeated effects across worker retries. Counting queue deliveries alone can mistake safe retries for duplicate business work.

For an illustrative daily report, one due occurrence with three worker attempts and one published result is one completed occurrence, not three successful jobs.

## Review by business zone

Inspect results around transitions and across the supported zones. A UTC-wide average can hide a defect affecting one local schedule window.

Keep zone labels bounded and avoid unnecessary user identifiers in metrics. Detailed occurrence history belongs in a controlled operational view.

Accept scheduling when expected occurrences reach the intended outcomes within the agreed timing policy. A healthy cron process or a high job-success percentage cannot establish that the correct local-time work was created in the first place.

## Sources

- [IANA: time-zone database](https://www.iana.org/time-zones)
