feat(ops): daily ops digest from the deep health probe (dispatch-only)#587
Conversation
Wave 2b. Surfaces the live deep /api/health signal (SLO counters, cache hit-rate, answer spend, degraded/truncation rates) proactively instead of only when someone looks. - scripts/ops-digest.mjs: dependency-free renderer that fetches the deep probe (x-health-deep-token) and renders a one-screen Markdown digest; an unreachable or degraded app IS the report (always exits 0). Emits status/alerting to $GITHUB_OUTPUT. Pure render + URL helpers are exported and tested. - .github/workflows/ops-digest.yml: SHIPPED DISABLED (workflow_dispatch only; schedule commented). Config via repo var PROD_HEALTH_URL + secret HEALTH_DEEP_PROBE_SECRET (nothing hardcoded). Keeps a rolling "ops-digest" issue updated and comments only when status != ok or spend alerts. Pinned actions, ubuntu-24.04, least-privilege permissions, preflight-secrets guard. - tests/ops-digest.test.ts: 6 offline tests (URL resolve, unreachable/healthy render, over-threshold + truncated flags). Enabling the daily cadence is an operator step (add var+secret, uncomment cron, run one dispatch to confirm). Verified: 6/6 vitest, check:github-actions, eslint, prettier — all green. No live calls in CI. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
Warning Review limit reached
Next review available in: 7 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8355970c03
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (out) writeFileSync(out, digest); | ||
|
|
||
| const status = health?.status ?? "unreachable"; | ||
| const alerting = Boolean(health?.spend?.alerting); |
There was a problem hiding this comment.
When the deep probe is reachable but the answer SLO counters are bad, /api/health still returns status: "ok" by design; src/lib/health-response.ts only uses reachability/config checks for liveness and currently returns slo/cache, not a spend block. Because this output is set only from health.spend.alerting, a spike in hybridRpcErrorRate, degradedRate, or truncation/timeout fallbacks leaves alerting=false, so the workflow just edits the rolling issue and does not comment or warn on the silent-degradation failure mode this digest is meant to surface. Evaluate thresholds from health.slo/health.cache here, or consume an alert field that the health endpoint actually emits.
Useful? React with 👍 / 👎.
| export function resolveHealthUrl(raw) { | ||
| if (!raw) return undefined; | ||
| const trimmed = raw.trim().replace(/\/+$/, ""); | ||
| if (/\/api\/health/.test(trimmed)) return trimmed; |
There was a problem hiding this comment.
If an operator sets PROD_HEALTH_URL to the full endpoint https://host/api/health without the query string, this branch returns it unchanged even though healthResponse only enables the diagnostic blocks when deep=1 is present. That run will authenticate with the token but receive the shallow health payload, so the digest can report ok while silently omitting the SLO/cache signals it was added to publish. Treat /api/health as a URL that still needs deep=1 unless the query already contains it.
Useful? React with 👍 / 👎.
1 participant
What
Wave 2b. Surfaces the live deep
/api/healthsignal (SLO counters, cache hit-rate, answer spend, degraded/truncation rates) proactively via a daily digest, instead of only when someone looks.scripts/ops-digest.mjs— dependency-free renderer that fetches the deep probe (x-health-deep-token) and renders a one-screen Markdown digest. An unreachable or degraded app is the report (always exits 0). Emitsstatus/alertingto$GITHUB_OUTPUT. Pure render + URL helpers exported and tested..github/workflows/ops-digest.yml— SHIPPED DISABLED (workflow_dispatchonly;schedulecommented out). Config via repo varPROD_HEALTH_URL+ secretHEALTH_DEEP_PROBE_SECRET— nothing hardcoded. Keeps a rollingops-digestissue updated and comments (notifies) only whenstatus != okor spend alerts. Pinned actions,ubuntu-24.04, least-privilegepermissions, preflight-secrets guard.tests/ops-digest.test.ts— 6 offline tests.Enabling (operator step)
PROD_HEALTH_URL(e.g.https://<app-host>)HEALTH_DEEP_PROBE_SECRET(same value as the deployment)schedule:block, run oneworkflow_dispatch, confirm the issue looks right.Verification
6/6 vitest,
check:github-actions(pin check), eslint, prettier — all green. No live calls run in CI; the workflow is dispatch-only until you enable it.🤖 Generated with Claude Code