$npx -y skills add softspark/ai-toolkit --skill healthService/infra health via liveness/readiness checks, resource usage, quick diagnostics. Triggers: health check, services up, system status, infra health, degraded service.
| 1 | # Health Check |
| 2 | |
| 3 | $ARGUMENTS |
| 4 | |
| 5 | Check the health of all project services. |
| 6 | |
| 7 | ## Project context |
| 8 | |
| 9 | - Services: !`docker compose ps 2>/dev/null || echo "no-docker"` |
| 10 | |
| 11 | ## Auto-Detection |
| 12 | |
| 13 | Detect services from `docker-compose.yml`, `.env`, or project configuration. |
| 14 | |
| 15 | ### Quick Check |
| 16 | ```bash |
| 17 | # If using Docker Compose |
| 18 | docker compose ps |
| 19 | |
| 20 | # Process check (bare metal) |
| 21 | ps aux | grep -E "(node|python|java|php)" | grep -v grep |
| 22 | ``` |
| 23 | |
| 24 | ## Common Service Checks |
| 25 | |
| 26 | | Service | Health Check | |
| 27 | |---------|-------------| |
| 28 | | HTTP API | `curl -f http://localhost:{port}/health` | |
| 29 | | PostgreSQL | `pg_isready -h localhost -p 5432` | |
| 30 | | MySQL | `mysqladmin ping -h localhost` | |
| 31 | | Redis | `redis-cli ping` | |
| 32 | | MongoDB | `mongosh --eval "db.runCommand({ping:1})"` | |
| 33 | | Elasticsearch | `curl -f http://localhost:9200/_cluster/health` | |
| 34 | | RabbitMQ | `curl -f http://localhost:15672/api/healthchecks/node` | |
| 35 | |
| 36 | ## Diagnostics |
| 37 | |
| 38 | ```bash |
| 39 | # Container logs (if Docker) |
| 40 | docker compose logs --tail 50 {service} |
| 41 | |
| 42 | # Resource usage |
| 43 | docker stats --no-stream # Docker |
| 44 | htop # Bare metal |
| 45 | |
| 46 | # Disk usage |
| 47 | df -h # System |
| 48 | docker system df # Docker |
| 49 | |
| 50 | # Network |
| 51 | netstat -tlnp # Listening ports |
| 52 | curl -I http://localhost:{port} # Connectivity |
| 53 | ``` |
| 54 | |
| 55 | ## Common Issues |
| 56 | |
| 57 | | Symptom | Check | Solution | |
| 58 | |---------|-------|----------| |
| 59 | | Service not responding | Process running? Port open? | Restart service | |
| 60 | | Slow responses | Resource usage, connections | Scale or optimize | |
| 61 | | Connection refused | Network, firewall, port | Check config | |
| 62 | | Out of memory | `free -h`, container limits | Increase limits | |
| 63 | |
| 64 | ## Automated Health Check |
| 65 | |
| 66 | Run the bundled script for a JSON health report: |
| 67 | |
| 68 | ```bash |
| 69 | python3 ${CLAUDE_SKILL_DIR}/scripts/health_check.py http://localhost:8000 |
| 70 | ``` |
| 71 | |
| 72 | ## Health Report Format |
| 73 | |
| 74 | ```yaml |
| 75 | services: |
| 76 | {service-name}: |
| 77 | status: healthy|degraded|down |
| 78 | uptime: Xd Xh |
| 79 | cpu: X% |
| 80 | memory: XMB |
| 81 | notes: "any issues" |
| 82 | ``` |
| 83 | |
| 84 | ## Rules |
| 85 | |
| 86 | - **MUST** report measured values — never mark a service healthy without a successful probe |
| 87 | - **NEVER** restart a degraded service without the user's explicit go-ahead |
| 88 | - **CRITICAL**: separate liveness (process up) from readiness (accepting traffic) in the report |
| 89 | - **MANDATORY**: if a health endpoint times out, classify as `degraded`, not `healthy` |
| 90 | |
| 91 | ## Gotchas |
| 92 | |
| 93 | - `docker compose ps` shows `Up` even when a container is **crash-looping** via restart policy — look at the `STATUS` column for `(unhealthy)` or `Restarting` rather than trusting "Up" alone. |
| 94 | - Many `/health` endpoints return 200 as long as the web server answers, even when the DB connection is down. If the service exposes a `/ready` or `/healthz?deep=true` endpoint, prefer it — shallow health is a lie. |
| 95 | - `pg_isready` reports success the moment Postgres accepts TCP, which happens seconds before the DB is actually query-ready after a restart. Chain it with a trivial `SELECT 1`. |
| 96 | - `docker stats --no-stream` needs cgroups v2 access; on older hosts or LXC containers it returns 0% CPU/memory silently instead of erroring. Verify at least one non-zero value before trusting the report. |
| 97 | |
| 98 | ## When NOT to Use |
| 99 | |
| 100 | - To debug a specific failing service — use `/debug` after the health check narrows it down |
| 101 | - For performance bottlenecks — use `/performance-profiling` |
| 102 | - For a production incident with page/alert — use `/workflow incident-response` |
| 103 | - For CI pipeline status — use `/ci` |