## TL;DR
Verification retries that spill into the backup window compete for the same repository, catalog locks and network the production backups need, and can make both fail. Give the agent a window awareness: read the backup schedule, stop starting retries when the window opens, park unfinished verification for the next quiet period, and alert if verification routinely cannot finish inside its own window.

```text
agent's retry loop collided with the backup window and failed the run
```

## Use this when
- Restore verification and nightly backups fail or slow each other on the same nights.
- Retry storms begin just before the backup window opens.
- Repository or catalog lock errors appear in both job logs.

## Not for this skill when
- Backups fail among themselves without any agent activity. Backup scheduling problem.
- The verification window is officially the same as the backup window by design. Then isolation, not timing, is the fix.

## Steps
1. Overlay agent retry timelines with backup job timelines for failing nights. Verify: the collision is evidenced in timestamps
2. Encode backup windows in the agent configuration, sourced from the backup schedule where possible. Verify: the agent knows current window boundaries
3. Make retry logic check window state and defer remaining retries to the next allowed period, checkpointing progress. Verify: a test retry defers at window start
4. Add reporting on verification that repeatedly misses its window so capacity or scope issues surface. Verify: chronic deferrals are visible weekly
5. Run a full cycle and confirm backups and verification stop colliding. Verify: both complete in their own windows

## Variant phrasings
### agent verification collides backup window schedule
The schedule phrasing.
### retry storm overlaps nightly backup jobs
The storm variant.
### defer agent work outside backup window
The defer wording.

Compatibility: Agents sharing repositories, catalogs and networks with Veeam, Commvault and similar nightly backup estates.

## Why it happens
Backup windows are protected time because production backups are both heavy and deadline-driven. An agent retry loop has no natural sense of that boundary; it sees only a failed task and a retry rule. Teaching it the calendar is simple, but it has to be explicit, because contention symptoms appear in both systems and each side blames the other.

## Edge cases / pitfalls
- Repository maintenance tasks like compact and defragment also own windows. Map all heavy neighbours, not just backups.
- If verification cannot fit outside windows, negotiate dedicated resources instead of stealing window capacity.
- Window definitions drift when backup schedules change. Pull them from the source system, not a copied note.

## Provenance

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