Repository navigation
Probe production health every 8 hours instead of every 15 minutes - #201
Merged
Merged
Conversation
Ninety-six scheduled runs a day was more than the signal warranted: the probe is a stopgap that notifies by email and Slack, not a pager, and a tick every eight hours still catches an outage within a shift. The tick sits off the top of the hour, where GitHub's scheduler is busiest. The job-timeout rationale no longer needs the arithmetic that assumed 15-minute ticks; the point stands, a wedged run must fail fast. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xd7VT72Qt16qiAJynu9EKj
MRmarioruci
approved these changes
Sep 24, 2026
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The focused workflow change has no unresolved issues.
Review effort: Balanced
Findings: None
What changed in this PR
Reduces production health probes from every 15 minutes to every 8 hours while preserving manual runs and timeout behavior.
Changes:
- Changes the cron schedule to
17 */8 * * *. - Updates cadence and timeout comments.
| File | Description |
|---|---|
.github/workflows/health.yml |
Updates the health-probe schedule and explanatory comments. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
Production healthworkflow ran on*/15 * * * *, ninety-six scheduled runs a day. That is more than the signal warrants: the workflow's own header calls it a stopgap that notifies by email and Slack rather than a pager, and a tick every eight hours still catches an outage within a shift. The schedule is now17 */8 * * *, three runs a day at 00:17, 08:17 and 16:17 UTC, off the top of the hour where GitHub's scheduler is busiest and most likely to run late.The comment on
timeout-minutesis reworded: its arithmetic ("24 missed probes" behind a wedged run) assumed 15-minute ticks. The point it made still holds and the 10-minute timeout is unchanged: a wedged run must fail fast rather than sit silent for the default 6-hour job timeout, since silence is indistinguishable from health.concurrencyand the manualworkflow_dispatchtrigger are untouched.Related issues
Follows #197, which pinned the Internet Identity this probe checks.
Changes
.github/workflows/health.yml— the cron expression and the two comments that described the old cadence. No step changes.Testing
schedule: [{cron: '17 */8 * * *'}]..github/scripts/scan-internal-identifiers.sh origin/main...HEAD— clean.workflow_dispatch, exercises it exactly as before.Checklist
🤖 Generated with Claude Code
https://claude.ai/code/session_01Xd7VT72Qt16qiAJynu9EKj
Generated by Claude Code