[spalen0]

What

timelock-alerts moves from the hourly profile to half_hourly (*/30 * * * *). Timelock alerts can now arrive up to 30 minutes sooner.

Why it's safe

• Reaction window: every monitored timelock delays operations by at least 24h. I checked the lowest delay seen in the indexed CallScheduled events for each timelock. The only one below 24h was Infinifi's Shorttimelock, which has switched between 1h and 24h. On-chain getMinDelay() = 86400 (24h) today, and it has been at 24h since 2026-08-16. The Longtimelock is 7 days. Lowering the delay again would itself have to go through the 24h timelock, so it would be alerted first. With 30 minutes, detection takes at most about 2% of a 24h window.
• Cursor: TIMELOCK_LAST_TS stays in the default cache-id.txt, because half_hourly, like hourly, has no cache override. The move skips and repeats nothing.
• Overlap: each profile runs under its own flock -n, so a slow run is skipped instead of overlapped. The script has no hourly assumptions; it's cursor-based, with a 12h fallback lookback.
• Indexer freshness: yearn-check-indexer-freshness stays hourly, which still covers a stalled indexer.

Also

• monitoring.yaml: the timelock card's cadence is now "Every 30 minutes (stale operations: daily)".
• The timelock README and runbook wording is updated, along with two comments that said "hourly".

Testing

• tests/test_monitoring_config.py and tests/test_automation_*.py pass (57).
• python -m automation render-crontab shows */30 … run half_hourly.
• run half_hourly --dry-run lists lender_borrower.py --checks=ltv and timelock_alerts.py, and run hourly --dry-run no longer includes the timelock task.
• The change reaches the box through the 10-minute sync, which re-renders the crontab; no restart is needed.

🤖 Generated with Claude Code