Ask Claude to Add Health Check Endpoints That Monitoring Tools Can Hit
Your app might boot fine but break five minutes later when Redis goes down or the disk fills up. Health check endpoints give monitoring tools a way to ask "are you still healthy?" at any time.
"Add health check endpoints to this project — /health for a quick
liveness check and /ready for a full readiness check of all dependencies"
Claude reads your project to understand which services you depend on, then generates endpoints that check them:
// GET /health → fast liveness check
{ "status": "ok", "timestamp": "2024-03-15T14:30:00Z" }
// GET /ready → full dependency check
{
"status": "healthy",
"checks": {
"database": { "status": "up", "latency_ms": 2 },
"redis": { "status": "up", "latency_ms": 1 },
"storage": { "status": "up", "free_gb": 45.2 },
"queue": { "status": "up", "pending_jobs": 12 }
}
}
You can customize what gets checked:
# Check external APIs your app depends on
"Add checks for the payment gateway, email service, and CDN availability"
# Add degraded states
"Return 'degraded' if non-critical services are down, 'unhealthy'
only if the app can't serve requests at all"
# Add version info for debugging
"Include the app version, deploy timestamp, and git commit hash
in the health response"
# Kubernetes-specific
"Add separate /healthz (liveness) and /readyz (readiness) endpoints
following Kubernetes conventions"
Wire the endpoints to your infrastructure:
- Load balancers hit
/healthto route traffic away from unhealthy instances - Kubernetes uses
/readyzto decide when to send traffic after a deploy - Uptime monitors poll
/readyand alert when dependencies fail - Dashboards display the detailed check results for the on-call team
You can't fix what you can't see — health check endpoints make your app's internal state visible to the systems that keep it running.
via Claude Code
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.