fix(ci): the freshness cron is shed 3-in-4, so trigger on the deploy instead (#3)

[mrveiss]

First, a correction

I previously reported "zero scheduled runs — the guard is not watching". That was false, and it is corrected on #3. The schedule fires:

2026-09-10T03:42:38Z  freshness [schedule] success
2026-09-09T23:53:27Z  freshness [schedule] success
2026-09-09T21:51:05Z  freshness [schedule] success

I published a strong negative from a single query that under-reported, when a second instrument was one call away. "Nothing found" versus "did not look" is the distinction this repository exists to enforce, and I collapsed a third case into it: looked with one tool that lied.

The real defect, which survives the correction

The schedule fires far below the requested cadence:

Requested	*/30 — every 30 minutes
Observed window	21:51:05 → 03:42:38 (5h 51m)
Runs	3
Expected	~12
Gaps	2h 02m, 3h 49m

GitHub sheds roughly three in four. That matters concretely: the drift window that motivated #3 was 40 minutes. A check with 2-to-4-hour gaps would most likely have missed it. The criterion was met literally while the guard stayed too sparse to catch the event it was built for — a more interesting failure than "it does not run", and a real one.

The fix is not a cron tweak

A cron cannot be made reliable by asking harder.

1. workflow_run on the Pages deploy completing. Event-driven, firing at exactly the moment drift either resolves or becomes permanent — including on a cancelled deploy, which is the case that holds a divergence open indefinitely and the one the Pages API mislabels as "Page build failed."

2. cron: '7,37 * * * *' replaces */30. Same cadence, off the :00 and :30 minutes where every scheduled job on the platform collides and is shed first. It is now a backstop, not the primary mechanism.

One thing is unverified, and the file says so

Whether workflow_run matches the dynamic pages build and deployment workflow is unknown. It is generated (dynamic/pages/pages-build-deployment), not a file in .github/workflows, and I do not know whether that affects name matching. The comment in the workflow states it outright:

UNVERIFIED … If no workflow_run-triggered run appears, this trigger is inert and the cron is all there is — do not assume it works because it is here.

The next deploy is the test, and I will report the result rather than assume. If it turns out inert, the honest outcome is that #3 stays open with the cron as a known-insufficient mechanism, not a ticked criterion.

Settle-retry, so it does not cry wolf

The check now runs on deploy completion, and a just-finished deploy can still be served from cache for a few seconds — so the first mismatch after a healthy deploy is expected. Three re-fetches at 20s intervals before concluding, with the distinction printed:

IN SYNC after settling 20s (cache lag, not drift).

vs

DIVERGENT: still differs after 60s -- not cache lag.

Without this, every successful deploy would likely produce a drift alert. A checker that cries wolf on every deploy is worse than no checker, which is the same lesson the preconnect false positive taught in #4 — and the reason that one was fixed before merge rather than tolerated.

Verification

• check_freshness.py run locally → IN SYNC, exit 0
• Workflow parses as YAML; triggers are schedule, workflow_run, workflow_dispatch; cron 7,37 * * * *
• Cache-lag path is code-reviewed but not exercised — it needs a real deploy to fire, which happens when this merges

Refs #3 — deliberately not Closes. The criterion this addresses cannot be verified by merging it; it needs an observed workflow_run-triggered run.

🤖 Generated with Claude Code