The task finishes. When does the next one begin?

Intervals advance from completion.

For the pinned Hermes implementation, a completed run records its completion time and computes the next occurrence from it. An interval adds its duration to that reference. A cron expression instead finds a matching future wall-clock time. MinuteField lets you supply a constant assumed task duration to make the difference visible.

The first interval run finishes at 12:35. Adding 30 minutes yields 13:05. For the cron schedule, the next matching slot after 12:35 is 13:00. The calendar shows starts; opening an event also shows its assumed completion.

Skipped clock slots are not overlapping appointments.

Change the assumed duration to 40 minutes. A 12:30 run finishes at 13:10. The interval’s next start becomes 13:40; the half-hour cron expression next matches 13:30. This rehearsal is a sequential calculation: it advances after a completed run and does not invent a second concurrent run at 13:00.

The assumed duration is a constant across every projected occurrence. It does not estimate a language model’s latency, a tool’s execution time or network delays. Try a short and a long plausible duration to understand sensitivity; do not interpret either scenario as a performance forecast.

A calendar is not the scheduler’s execution history.

Real execution can depend on gateway availability, queueing, manual triggers, retries, task failures, provider limits and missed-fire policy. Those mechanisms can change what actually runs. MinuteField deliberately labels each result as a nominal occurrence under successful sequential completion.

An empty month can also be an ordinary preview limit. Each schedule returns at most the selected number of occurrences, up to 200. For a frequent interval, they may all fall in one day. The date range beneath the calendar makes that truncation visible; it is not a claim that the schedule ends there.

For one-shots, there is no second occurrence regardless of how large the count is. A zero interval is accepted by the native parser but cannot produce useful advancing dates. The preview exposes that result and stops rather than filling a calendar with identical instants.

1. Verify the schedule kind and several next occurrences.
2. Repeat with a realistic nonzero task duration.
3. Check the timezone, particularly around a clock change.
4. Create a small real test in your own Hermes installation, then inspect actual execution and delivery separately.

The implementation reference is 0.22.2’s completed-run recording, advancement and next-run functions. For operational missed-fire behavior, use the documentation for your installed version. See also the exact engine and verification scope.

A changing duration can hide inside an average.

Use an original hand-calculated example: both schedules first start at 12:30 UTC. The first run lasts two minutes, the second lasts 38 minutes and the third lasts four minutes. This sequence is hypothetical; it is not a record of Hermes execution. The calendar accepts one constant duration, so use this written trace to understand what that simplifying assumption leaves out.

For the interval, add 30 minutes to each finish. For cron, find the next half-hour boundary strictly after that finish in this example. The long second run crosses 13:30; this sequential calculation therefore advances to 14:00. It does not place a second task at 13:30 while the first is still running.

The arithmetic average is 14 minutes 40 seconds, but substituting that value everywhere gives a different sequence. In particular, cron would not cross the same clock boundary on its second run. Average runtime is a useful summary of completed work; it is not enough to reconstruct the time of every future occurrence.

Choose a rehearsal that answers your actual question.

If you need a quiet interval after work finishes, compare the interval with both a short and a long duration. If you need output ready by a wall-clock deadline, write the deadline separately and compare it with completion, not merely the start shown in the calendar. Neither strategy promises completion by a deadline when task duration is unknown.

For a real trial, keep four timestamps per run: nominal due time, observed start, observed completion and observed delivery. A 12:30 due time, 12:34 start, 12:39 completion and 12:41 inbox receipt describe three different delays. Changing the schedule expression cannot by itself identify which delay caused a late message.

Keep this arithmetic trace and the four-timestamp trial sheet. It contains no executable scheduling command. Compare it with the delivery rehearsal before asking a real agent to send anything.