fix(health): liveness must not fail on something a restart cannot fix - #153
Merged
Merged
Conversation
#151 made /api/health return 503 whenever the LLM chain was down. That is right for alerting and wrong for liveness: restarting botsmann does not repair an expired Groq key, so the only effect of failing there is to get a healthy process killed, and to fail deploy gates on a problem no deploy caused. That is the failure class that teaches people to bypass the gate. GET /api/health liveness -- 200 while the process serves and the database answers. The body still carries status: healthy | degraded | down and the full llm block, so the outage stays visible. GET /api/health?strict=1 readiness -- 503 once the chain is consistently failing. Point alerting here. 'unknown' (nothing has exercised the chain since this process started) is not evidence of a problem, so it reports healthy rather than degraded. The deploy gate was never at risk -- selfhost-deploy.yml curls the homepage, not this endpoint -- but the shape was wrong regardless, and the guidance in CLAUDE.md does point a post-deploy check at /api/health. The guard now asserts the 503-on-LLM path stays behind `strict`, so this cannot quietly become unconditional again. verify: format, lint, typecheck, 269 tests, build -- all green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HVwg8DKHQktxJuHeLM3xpG
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
1 participant
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.
#151 made
/api/healthreturn 503 whenever the LLM chain was down. That's right for alerting and wrong for liveness: restarting botsmann doesn't repair an expired Groq key, so the only effect of failing there is to get a healthy process killed — and to fail deploy gates on a problem no deploy caused. That's precisely the failure class that teaches people to bypass the gate.Two flavours
GET /api/healthstatus: healthy | degraded | downand the fullllmblock, so the outage stays visible.GET /api/health?strict=1unknown— nothing has exercised the chain since this process started — is not evidence of a problem, so it reports healthy rather than degraded.Was anything actually broken?
No.
selfhost-deploy.ymlcurls the homepage, not this endpoint, so the deploy gate was never at risk. But the shape was wrong regardless, and the post-deploy guidance in CLAUDE.md does point a check at/api/health.Guard
The test now asserts the 503-on-LLM path stays behind
strict, so it can't quietly become unconditional again.Verify
format:check,lint,typecheck, 269 tests,build— all green.🤖 Generated with Claude Code
https://claude.ai/code/session_01HVwg8DKHQktxJuHeLM3xpG