health-check

Health Check — Proactive Health Inspection

Directly query CloudWatch metrics to determine service health, without relying on alarm configuration.

Relationship with other skills

• env-discovery: "What resources exist" → health-check: "Are the resources healthy"
• health-check Anomaly found → log-diagnosis Drill down into logs → aws-troubleshooting In-depth investigation
• health-check Alarm found → incident-triage Triage

Workflow

Step 0 — Confirm scope

MUST:

• Confirm inspection scope: global vs single service
• Confirm region (default ap-northeast-1)
• Confirm time window (default last 1 hour)

Step 1 — Run health check

MUST:

• Run scripts/check-health.sh <account-id> <region> to get the health summary
• If a single service, add --service <name> to filter
• The script automatically discovers EKS / RDS / ALB resources and queries metrics

SHOULD:

• If the script returns UNKNOWN (no metric data), prompt the user that Container Insights or related monitoring may not be enabled

Step 2 — Analyze metrics

MUST:

• Read references/health-metrics.md to understand the meaning and thresholds of each metric
• Determine the health level of each service: HEALTHY / DEGRADED / CRITICAL / UNKNOWN
• If SLO definitions exist, compare actual values vs. targets.Read references/slo-targets.local.yamlfirst (the real targets for your environment, gitignored); if it does not exist, fall back to the example references/slo-targets.yaml

SHOULD:

• Watch the trend — is the metric worsening or stable
• Check correlations across multiple metrics (e.g., high CPU + low memory may indicate frequent GC caused by a memory leak)

Step 3 — Output report

MUST:

• Use assets/health-report-template.md format output
• Include: overall status, per-service health status, anomaly details, alarm status, SLO compliance
• Highlight CRITICAL and DEGRADED services

Step 4 — Follow-up suggestions

SHOULD:

• DEGRADED/CRITICAL → suggest using log-diagnosis to check logs
• Alarm triggered → suggest using incident-triage for triage
• Need in-depth investigation → route to aws-troubleshooting (real-time query aws-knowledge MCP / SSM Automation)
• No data (UNKNOWN) → suggest enabling monitoring (Container Insights, RDS Enhanced Monitoring, etc.)

Query reference

• Health metrics and thresholds for each service:references/health-metrics.md
• SLO target definitions:references/slo-targets.local.yaml(real, gitignore) takes priority, otherwise references/slo-targets.yaml(example template)

Automation Boundary

auto-safe

• aws cloudwatch get-metric-data / get-metric-statistics
• aws cloudwatch describe-alarms
• aws eks list-clusters / describe-cluster
• aws rds describe-db-instances / describe-db-clusters
• aws elbv2 describe-load-balancers / describe-target-health
• Run scripts/check-health.sh
• to generate a health report

human-required

• None (pure read-only skill)

Gotchas

• Container Insights is not enabled by default — if all EKS metrics are UNKNOWN, it's not that the cluster has a problem, it's that monitoring isn't enabled
• The behavior of RDS FreeableMemory on Aurora differs from standard RDS — Aurora actively uses memory for caching, so low FreeableMemory is not necessarily a problem
• CloudWatch metrics have ~2 minute delay, so data from the last few minutes may be incomplete
• ALB p99 latency requires Extended Statistics to be enabled; standard statistics only have Average/Sum/Min/Max
• No alarm configuration (ap-northeast-1 currently has 0 alarms) does not mean the environment is healthy — this is why this skill directly queries metrics
• check-health.sh uses macOS-compatible commands (sed instead of grep -P). If you encounter sed behavior differences on Linux, check GNU vs BSD sed