## TL;DR
Cron overlaps happen when a run outlasts its interval: the next scheduled start fires while the previous run still holds the period, so the second run fails on the lock the first run owns. Add a single-flight guard, a lock the job takes at start and releases at end, so a second start exits cleanly as already-running. Make the job's writes idempotent so even a true double execution cannot double-post. Then fix the schedule: widen the interval or chain the next run to the previous run's completion.

```text
agent's scheduled close job ran twice on a cron overlap and the second run failed on the period lock
```

## Use this when
- Close job logs show two concurrent runs of the same job, with the second failing on a period lock.
- The job's runtime sometimes exceeds its cron interval.
- Each run's writes are not guarded against duplicates.

## Not for this skill when
- Two different jobs conflict on the same period. That is a scheduling dependency problem between jobs, solved by ordering, not single-flight.
- The period lock failure is from a human also working the period. Coordinate the human and the job rather than changing the schedule.

## Steps
1. Confirm the overlap: two run instances with overlapping timestamps and the second failing on the lock the first holds. Verify: the run history shows the collision, not just the failure
2. Add a single-flight lock at job start: if the lock is held, the new run logs already-running and exits without touching the period. Verify: a forced double start exits cleanly in a test
3. Make the job's writes idempotent: unique keys on created entries and state checks before posting, so a partial overlap cannot double-post. Verify: a simulated partial double run creates no duplicates
4. Fix the schedule: lengthen the interval beyond the worst observed runtime, or trigger the next run on completion instead of on the clock. Verify: the new schedule cannot self-overlap under observed runtimes
5. Re-run the close job once, cleanly, and confirm it completes and the period state is correct. Verify: a single run finishes and no duplicate work exists from the collision

## Variant phrasings
### cron overlap close job ran twice period lock
The double-run phrasing.
### scheduled job single flight lock idempotent close
When adding the guard.

Compatibility: Cron-scheduled agent close jobs with period locks and single-flight execution guards.

## Why it happens
Cron is time-based, not completion-based: it starts jobs whether or not the previous instance finished. Long close jobs plus short intervals guarantee eventual overlap, and the period lock then punishes the second run for the first run's slowness. Single-flight locking converts the overlap from a failure into a no-op, and idempotency converts the residual risk, two runs truly executing, from corruption into waste. The schedule fix removes the overlap at its source.

## Edge cases / pitfalls
- A lock held by a crashed run can block all future runs; the single-flight lock needs its own expiry or heartbeat so crashes self-clear.
- Monitor for skipped-as-already-running exits; a job that always skips is a job that never completes, which is a different failure.
- Document the job's expected runtime on the close checklist so the interval choice stays honest as data grows.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zalmRRszKhdub9bYW8pAnQ