Confirm the org sweeps actually fire on schedule

[ExtraToast]

What to build

org-project-sweep.yml is now the only thing boarding issues and pull requests from the private repos — their per-repo shims were removed in #33 once the sweep was proven working. The sweep itself is verified: dispatched manually it boarded 174 items across 30 repos with zero failures.

Its schedule has not been observed to fire. The workflow landed on main at roughly 18:47Z on 2026-08-29 and is registered active with cron: '*/15 * * * *', but 40 minutes later every run in its history is still the manual dispatch. The 19:00 and 19:15 slots both passed with nothing.

This may well be nothing — GitHub takes an unspecified amount of time to begin running a newly added schedule, and */15 is the tier most aggressively delayed or dropped under load. But it is currently an assumption, and the thing it is an assumption about is whether issues reach the board at all.

Confirm the schedule actually fires, and decide what to do if it turns out */15 is unreliable here.

The failure mode is delay, not loss. The sweep is idempotent and boards everything open each time it runs, so a missed tick is caught by the next one. Nothing is dropped permanently — items simply arrive late, and if the cron never fires they never arrive at all until someone dispatches it by hand.

If */15 proves unreliable, a slower cadence is likely to be more reliable rather than less; GitHub deprioritises the high-frequency tiers first. Boarding does not actually need 15-minute latency.

Worth watching alongside this: org-hygiene-sweep.yml runs 25 */6 * * * and has the same open question, though its first slot is further out.

Acceptance criteria

• At least one schedule-triggered run of the project sweep is observed to have completed successfully
• The typical delay between the cron slot and the run actually starting is noted, so future expectations are calibrated
• If the schedule proves unreliable at */15, a cadence that does fire dependably is chosen and the reasoning recorded
• The same confirmation is made for the hygiene sweep
• If neither schedule fires within a day, treat boarding as broken and restore an interim path rather than leaving private repos unboarded

Blocked by

• None — can start immediately, but it is mostly waiting and observing.

[ExtraToast]

Diagnosed. It is not registration delay — it is throttling, and it is org-wide.

Still zero scheduled runs 80+ minutes after merge. But the workflow is fine: on.schedule[0].cron parses correctly as */15 * * * * from main, and the manual dispatch works. The problem is that GitHub is delivering only a few scheduled runs per repo per day in this org, largely regardless of the declared frequency.

Measured against the estate's existing schedules:

workflow	declared	actually delivered
Auto Bump First-Party Images (fleet-infra)	*/30 — 48/day	2–4/day
App Key Age Watchdog (fleet-infra)	0 6 * * *	1/day, firing 12:22 / 18:14 / 17:21 — 6–12h late
Fragment Drift (fleet-infra)	17 6 * * *	1/day, firing 12:43 / 18:47
Sync Submodules (workspace)	0 4 * * *	1/day, firing 10:40 / 15:51 / 14:55
all schedules, fleet-infra + workspace	—	4–7/day combined

Auto Bump is the clearest signal: 48 scheduled firings a day deliver two to four. Roughly 5%.

What this means

Raising or lowering the cron frequency will not fix this — the delivered count looks capped per repo per day, so */15 and hourly land in much the same place. The org's .github repo may get its own allocation, but nothing here suggests it will be materially better.

So boarding latency is now hours, not minutes. That is a real regression from the event-driven shims, which boarded instantly. It is degradation rather than loss — the sweep is idempotent and boards everything open whenever it does run — but the acceptance criterion in this issue ('at least one schedule-triggered run observed') is the wrong bar. The right question is whether hours-long boarding latency is acceptable.

That is a judgement call, not a bug to fix, so it goes back to the owner rather than being decided here. Three options, in increasing cost:

1. Accept it. It is a project board; items arrive within a few hours and nothing is lost. Costs nothing.
2. Restore event-driven boarding in fleet-infra only — the highest-traffic private repo at ~85 events/month, so ~85 billable minutes. Instant boarding where most of the volume is; the sweep still covers the rest.
3. Restore all four private shims — ~516 minutes/month, which undoes most of what Drop per-repo Add to Project shims from the private repos #33 bought.

Leaving this issue open pending that decision. Also worth noting for #126: a watchdog that assumes its own schedule fires on time will be wrong in this org.

[ExtraToast]

Resolved for the repo that mattered; the underlying question stays open.

Option 2 taken: event-driven boarding restored in fleet-infra only, via JorisJonkers-dev/fleet-infra#171 (merged). That repo carries most of the estate's issue and pull request volume, so it gets instant boarding for roughly 85 billable minutes a month. workspace, nix-config and homelab-collections stay on the sweep and keep the large majority of what #33 bought.

Estate total moves from ~505 to ~590 billable minutes a month, still under 20% of the cap.

What is fixed: the repo where hours-long boarding latency was actually felt.

What is not: the sweep still has never fired on schedule. The other three private repos, and the hygiene sweep, remain on whatever cadence GitHub decides to give them — measured at four to seven scheduled runs a day across an entire repo, regardless of declared frequency. For low-volume repos that is acceptable; it is the reason option 2 was scoped to one repo rather than all four.

Worth keeping this issue open to record the first schedule-triggered run whenever it appears, because that number calibrates what any future scheduled work in this org can assume. Specifically it bears on JorisJonkers-dev/github-workflows#126: a budget watchdog on a cron that fires a handful of times a day at unpredictable hours cannot promise to warn before a cap is hit, and should be designed knowing that rather than discovering it during the next outage.

Double boarding in fleet-infra is harmless — addProjectV2ItemById returns the existing item on a re-add, the same idempotency that makes the sweep safe to run repeatedly.