Schedule-Driven Jobs

Some Hop links have an expiry date. At the moment a link expires, nothing happens — nobody clicks a button, no message is sent. Time simply passes. Work like this cannot wait for an event, because there is none. It needs the clock.

The rule

No event to wait for? Let the clock start the job.

A schedule-driven job runs at fixed times or intervals: every night at 03:00, every hour, every Monday. Typical uses:

• clean-up: disable expired links, delete old temporary files
• roll-ups: turn a day's raw click events into daily totals
• reports and reminders: a weekly usage email
• checks: compare records between two systems and flag differences

On one machine this is often a cron line:

The clock is simple; the surprises come from the world around it:

• Several servers. If all three Hop servers carry the same cron line, the job runs three times. Use one scheduler, or let each server try to take a lock and let only the winner run.
• Overlap. If a run takes longer than the interval, the next one starts on top of it. Skip a run while the previous is still going.
• Missed runs. The machine was down at 03:00. The job should catch up, not skip a day's work forever.

The shortcut

Write the job so it asks "what is still left to do?" instead of "what happened since last time?" Then missed runs catch up and repeated runs do nothing harmful.

The trap is the job that works on your laptop and runs three times in production.

Drills

Answer fast — trust the rule.

Remember

• No event to wait for? Let the clock start the job.
• Shortcut: ask "what is still left to do?", not "what happened since last time?"
• Trap: duplicate runs across servers, overlapping runs and silently missed runs.